The other day I was asked to check a hacked trunk in a pbx box. While I was digging through the logs the owner complaint that he couldn't use a tool from the pbx interface, the "Call Event Logging" tool because of some error.

The error was: "General error: 1194 Table 'cel' is marked as crashed and should be repairedFile:/var/www/html/admin/libraries/BMO/Database/PDOStatement.class.php:17"

That is a simple one error to fix, the cel table is in the asteriskcdrdb database:

mysql asteriskcdrdb
repair table cel; 

That's all, the table was repaired

+-------------------+--------+----------+-----------------------------------------------+
| Table             | Op     | Msg_type | Msg_text                                      |
+-------------------+--------+----------+-----------------------------------------------+
| asteriskcdrdb.cel | repair | info     | Key 1 - Found wrong stored record at 27271156 |
| asteriskcdrdb.cel | repair | warning  | Number of rows changed from 180284 to 180281  |
| asteriskcdrdb.cel | repair | status   | OK                                            |
+-------------------+--------+----------+-----------------------------------------------+
3 rows in set (4.98 sec)

Well I had created my new repo, made the files I wanted and when I tried to push them:

error: src refspec master does not match any.

BUT...I have not committed anything yet oops!

So the correct order is:

Create my new shiny git repo

mkdir repo && cd repo
git remote add origin /path/to/origin.git

Add the files I want

git add . 

Commit the changes

git commit -m "initial commit"

Then push them!

git push origin master

And..success!

install drush on cpanel based servers with EA4 per account

1) cpanel already has composer if EA4 /opt/cpanel/composer/bin

2) enable jailed shell access to account

3) ssh to server with account creds or keys or root and then su to user

4) composer require drush/drush:7.*

5) go to .bashrc and make an alias

alias drush-master=~/.config/composer/vendor/drush/drush/drush

6) source .bashrc to make changes immidiately availabe

7) go to drush folder and do composer install to fetch dependencies

8) drush-master status to check it is working

9) change tmp to be inside USER home just in case

go to .bashrc and put the line

TEMP=~/tmp

if you cannot edit .bashrc write this on cli EXPORT TEMP=~/tmp

you can see the change in drush-master status

10) now go to ~/public_html/sites/default/

execute drush status and see that drush sees your website

You want to flush your DNS cache in linux? Well it is very very easy :]

Let's say you use systemd-resolve:

easy!

$ systemd-resolve --flush-caches

Let's say you use anything else (nscd, dnsmasq, named etc)

easier!

just restart the service

$ systemctl restart nscd (or dnsmasq, named etc)

or if you do not use systemd, you could try

service nscd restart

cheers!

PS: you probably need to have root privileges to execute the above commands

θέλοντας να προσθέσω έναν client σε έναν nagios Monitoring server, ακολούθησα την τυπική διαδικασία:

-install nagios plugins -install nrpe -check nrpe config -open firewall ports etc

όλα παίζουν σωστά λοιπόν, NOT!!
μετά από λίγα λεπτά στον monitoring server άρχισαν να βαράνε τα νταούλια του nagios για unknown problems και τέτοια αγχωτικά.

Ξανακοιτάω τα πακέτα, τίποτα όλα κομπλέ..
βάζω το nrpe να βαστάει debug log και δεν βλέπω κάτι ενδιαφέρον:

[1509568185] Running command: /usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/mapper/home
[1509568185] Command completed with return code 3 and output:
[1509568185] Return Code: 3, Output: NRPE: Unable to read output

Οπότε λέω να δοκιμάσω να τρέξω την εντολή να δω τι βγάζει.Άλλωστε από το log φαίνεται πως ο remote server κάνει την κλήση, αλλά εδώ κολλάει.

$ /usr/lib64/nagios/plugins/check_disk -w 20% -c 10% -p /dev/mapper/home

-bash: /usr/lib64/nagios/plugins/check_procs: No such file or directory

What?? Τι είν τούτο? Αφού έβαλα τα πακέτα nagios-plugins και nagios-plugins-nrpe...
και φυσικά αυτά ΔΕΝ εγκαθιστούν τα plugins του nagios...
Απότι φαίνεται στο centos 7 υπάρχουν χωριστά πακέτα, ένα για κάθε plugin. 2 ώρες χαμένες από τη ζωή μου...

Ε τα έβαλα και ησύχασα :]

Ξαφνικά χωρίς λόγο και αιτία, το webmail δεν δείχνει κανένα email, τα emails κολλάνε στην ουρά και όταν κοιτάς το log βλέπεις ένα κάρο debug info σχεδόν ακατανόητο.

Φυσικά μιλάμε για τον dovecot server που αναλαμβάνει τις συνδέσεις pop/imap.
Το κλειδί εδώ είναι μέσα στο χάος του log να βρούμε το σημείο που αρχίζει το πρόβλημα. Αν λοιπόν δούμε τη γραμμή:

Panic: file mail-index-sync-keywords.c: assertion failed

τα πράγματα ξεκαθαρίζουν γρήγορα. Ο dovecot μας λέει πως δεν μπορεί να κάνει sync το index του mailbox.
Ο λόγος είναι πως το αρχείο dovecot.index είναι corrupted και η λύση απλή:
σβήνουμε το αρχείο dovecot.index και κάνουμε εκ νέου ένα login στο webmail για να ξαναδημιουργηθεί!

Αν μόλις βάλατε το νέο σας template και πατώντας σε οποιοδήποτε article αντί να το δείτε , βλέπετε ένα κουφό σφάλμα

500 - JHtml: :icon not supported. File not found

μην απελπίζεστε, υπάρχει λύση.

Κάνοντας λίγο debugin' το joomla επειδή το ζητά το template, ψάχνει να βρει το αρχείο icon.php στο libraries/joomla/html/ αλλά δεν το βρίσκει. Η λύση λοιπόν είναι να το αντιγράψουμε από το components/com_content/helpers/ στο libraries/joomla/html/ και et voila, παίζουν όλα σωστά!

njoy

αν αναρωτιέστε γιατί δεν μπορείτε να στείλετε email από το νέο vps σας σε webmin, μην ψάχνετε πολύ μακρυά. Στο /var/log/mail.warn αν δείτε την παρακάτω γραμμή:

warning: SASL authentication failure: cannot connect to saslauthd server: No such file or directory

o server σας λέει πως δεν μπορεί να βρει τον sasl daemon, συνεπώς δεν μπορεί να κάνει authentication. Ο λόγος είναι πως λείπει το αρχείο

/var/run/saslauthd

το οποίο προσπαθεί να προσπελάσει για να διαπιστώσει αν τρέχει ο δαίμονας.

Στην πραγματικότητα το αρχείο βρίσκεται στο

/var/spool/postfix/var/run/saslauthd

οπότε με ένα symlink θα διορθωθεί το πρόβλημα:

ln -s /var/spool/postfix/var/run/saslauthd /var/run/saslauthd

Well...for some reason ssh failed to bind to any port other than 22

Lets check first to what port we are trying to bind to

$ cat /etc/ssh/sshd_config | grep -i port

$ Port 5678

Ok now let's check what the logs said (yes it's systemd...)

$ journalctl -u sshd.service

systemd[1]: Starting OpenSSH server daemon...
 sshd[10158]: error: Bind to port 5678 on 0.0.0.0 failed: Permission denied.
 sshd[10158]: error: Bind to port 5678 on :: failed: Permission denied.
 sshd[10158]: fatal: Cannot bind any address.

Permission denied? I bet it is because selinux is in enforce mode! So the solution is to add the port we want to the selinux policy about ssh.

Firstly lets install the policy utils

$ yum install policycoreutils-python

Check current policy for ssh

$ semanage port -l | grep ssh

ssh_port_t        tcp      22

And add to it our desired port

$ semanage port -a -t ssh_port_t -p tcp 5678

ready!

Αν διαχειρίζεστε cpanel server και λάβετε email σχετικά με κάποιο process upcp που ήδη τρέχει τα πράγματα είναι απλά:

μην πάτε να κλείσετε το process! Εκτός από κάποιες κουφές περιπτώσεις όπου το cpanel update process έχει κολλήσει από την προηγούμενη φορά που έτρεξε, το πιθανότερο είναι απλά να έχει ξεμείνει κάποιο process του crond.

Τρέξτε

ps aux | grep crond

και αν δείτε παραπάνω από ένα process ή σκοτώστε αυτό που νομίζετε πως είναι περιττό ή σκοτώστε τα όλα και τρέξτε ξανά το crond

easy ;)