HTOP per veure com està la Raspberry Pi

HTOP

I després d’instal·lar-hi un bon grapat de paquets, com sabem si està bé i pot aguantar encara més càrrega la nostre Raspberry Pi? doncs coneixia el comandament top, però no htop (https://htop.dev), que permet veure a temps real la monitortizació i estat d’un equip amb LINUX.

HTOP

Jo he trobat que la meva distribució ja el tenia instal·lat, però sinó només cal fer:

sudo apt-get install htop

i per executar-ho

sudo htop

resultat de la sentència htp

Tot i tenir una pantalla text o shell, podrem personalitzar alguns paràmetres com els colors, el mode de representar gràficament alguna informació o el fet de mostrar més detall d’alguns procesos. Excepcional i imprescindible!

Corregir permisos httpdocs i plesk

Ja m’he trobat en més d’una ocasió que per motius “desconeguts” els permisos dels arxius d’una carpeta httpdocs -o /var/www- d’un servidor (habitualment amb PLESK), perd la seva configuració de permisos.

El resultat en un servidor administrat amb PLESK és que perds mínimament les avantatges que et proporciona aquest gestor d’arxius. Automatitzacions automàtiques o simplement gestions sobre dominis les deixes de poder fer.

Finalment he trobat una bona guia que no voldria perdre. S’han de fer dos pasos:

Primer:

chown -R nomusuariPLESK:psacln /ruta_del_servidor/httpdocs

Amb aquesta primera sentència rerstaurarem de manera recursiva a tots els permisos per al grup “psacln” de la ruta que l’indiquem. Important serà posar correctament també el nom d’usuari plesk que ha de treballar en aquesta ruta.

Segon:

chown nomusuariPLESK:psaserv /ruta_del_servidor/httpdocs

Amb aquesta segona sentència resolem un problema (hem assignat els mateixos permissos a arxius i a directoris). Assignem al directori al grup “psaserv” -que amb la primera sentència hem assignat a arxius i directoris el mateix grup-.

Font: https://www.orware.com/blog/tips-and-how-tos/plesk/correct-httpdocs-permissions

Permisos d’arxiu d’un WordPress

wordpress-1084758_640Després d’una migració de servidor, sempre va bé revisar que els permisos de tots els arxius i carpetes d’un wordpress estiguin bé per evitar sustos posteriors.

Hi ha bàsicament tres permisos:

Les carpetes han de tenir els permisos 775
Els arxius han de tenir els permisos 664
i l’arxiu principal wp-config.php ha de ser 660
I tot això ho podem fer amb tres sentències linux fàcils i ràpides:

sudo find . -type f -exec chmod 664 {} +
sudo find . -type d -exec chmod 775 {} +
sudo chmod 660 wp-config.php

D’aquesta manera, podem validar que tota la estructura d’arxius i carpetes està amb els permisos que li pertoquen.

Buscar arxius grans en linux

Si necessites buscar els arxius més gran d’un tamany concret a linux has de fer:

find . -size +1000M

Entenent que buscarà des del pun on s’executi la comanda. Ens donarà diferents resultats la comanda si l’executem des de /home o de des de /var/www per exemple.

Netejar /var/spool/mqueue automàticament

Després de l’artí­cle anterior (Netejar /var/spool/mqueue i inodes plens) he pensat que això es podria automatitzar d’alguna manera per tal que no es generi de nou una carpeta amb un volum desmesurat d’arxius.

He afegit una entrada al crontab amb la següent informació:

crontab -e

0 0 * * * /usr/bin/find /var/spool/mqueue -mtime +2 -exec /bin/rm -f {} \;

De manera que cada dia a les 0:00 netejarà els arxius que siguin més antics a dos dies (-mtime +2) de la carpeta /var/spool/mqueue

 

Netejar /var/spool/mqueue i inodes plens

Les últimes setmanes m’he trobat que el servidor local dedicat a servir les dades meteorològiques no podia escriure més arxius.

Si feia un df -k tenia espai per escriure a totes les seves particions, però en canvi a efectes pràctics no era així­. Investigant, vaig descobrir que tenia espai per escriure però no hi havia espai disponible per més inodes 

10:~# df -hi
S. fitxers           Nodes”i   En ús Lliures   %Ús Muntat a
/dev/sda1               743K    743K       1  100% /
tmpfs                   127K       5    127K    1% /lib/init/rw
udev                    126K     499    125K    1% /dev
tmpfs                   127K       1    127K    1% /dev/shm

Buscant, on pot estar perdent-se tot aquest espai en arxius petits descontrolats he trobat que a la carpeta  /var/spool/mqueue  s’acaba emmagatzemant arxius pendents d’enviament de correu electrònic (d’alertes, logs, etc)… i que al intentar eliminar-los amb un rm -r *   acabava amb un missatge d’error:

10:/var/spool/mqueue# rm * -r
-bash: /bin/rm: La llista d’arguments és massa llarga

Total, per fer neteja he seguit una petita guia (http://docs.oracle.com/cd/E23824_01/html/821-1454/mailadmin-138.html) i he fet el següent:

– Aturar el servei de correu electrònic momentàniament

10:/var/spool/mqueue# /etc/init.d/sendmail stop
Stopping Mail Transport Agent (MTA): sendmail.

– Moure la carpeta /var/spool/mqueue a una antiga per eliminar-la i crear una de nova amb els seus permisos corresponents.

10:/var/spool# mv /var/spool/mqueue /var/spool/mqueue-fixme
10:/var/spool# mkdir /var/spool/mqueue
10:/var/spool# chmod 755 /var/spool/mqueue
10:/var/spool# chown root:daemon /var/spool/mqueue

– Un cop fet això, eliminar tot el contingut de la carpeta temporal mqueue-fixme. El procès ha trigat com uns 15 minuts

10:/var/spool# cd mqueue-fixme/
10:/var/spool/mqueue-fixme# ls | xargs rm -f ‘{}’

Però en acabar torno a tenir espai de sobres per què la màquina segueixi mostrant la informació meteorològica

10:/var/spool/mqueue-fixme# df -i
S. fitxers           Nodes”i   En ús Lliures   %Ús Muntat a
/dev/sda1             760368  176986  583382   24% /
tmpfs                 129303       5  129298    1% /lib/init/rw
udev                  128190     499  127691    1% /dev
tmpfs                 129303       1  129302    1% /dev/shm

Arrancar servei snmpd al reiniciar sistema

Si tens un servei snmpd en un servidor CENTOS, podria donar-se el cas que al reiniciar el sistema no arranqui o aixequi el servei snmpd.  Per defecte, quan instal·lem aquest servei no queda programat per què s’encengui.

Per fer-ho tindrem dues opcions:

La més habitual seria afegir aquest servei als sistema d’arrancada:

 chkconfig –level 345 scriptname on

Un altre opció, que he trobat i és potser més intuïtiva és simplement dir-li que

chkconfig NOMSERVEI on

chkconfig snmpd on

Amb això quan tornem a reiniciar el sistema haurí­em de trobar que aixeca el servei automàticament.

Font: http://support.suso.com/supki/CentOS_Init_startup_scripts

 

Reiniciar DSL automàticament quan cau l’ADSL

Més sovint del que voldrí­em, almenys a mi em passa, l’ADSL queda com “col·lapsada” i deixa de funcionar.  La solució és ben fàcil, aixecar-te anar al router, reiniciar-lo i automàticament tornes a tenir internet.

El problema s’agreuja, quan tens algun petit servidor i estàs en remot treballant contra aquests serveis.   Mai havia tingut el temps, però aprofitant una tarda “relaxada”, he buscat i adaptat un script per què una màquina linux estigui monitoritzant si té internet o no, i en el cas que pel que sigui no hagi internet reiniciï la interfí­cie DSL del router de manera que torni a restablir el servei ADSL evitant haver d’anar a casa a reiniciar el router.

Requisits: una màquina linux a casa. En el meu cas una màquina amb debian.

Crearem un arxiu reset-dsl.sh i li afegirem el següent contingut:

#!/bin/bash
# Definim on volem fer ping potser 8.8.8.8, una ip pública o la IP del nostre servidor DNS
desti=8.8.8.8
if `ping -c 5 $desti> /dev/null` ;then
 echo Destí­ està Online
 #Tenim internet i ens dirà "Desí­ està online"
else
 #No tenim internet per tant iniciarem el reinici del servei
 echo Destí­ està Offline
 echo Reiniciant ADSL
Router-DSL=1.2.3.4
 #Aquí­ haurem d'introduïr la IP del nostre router d'internet
 port=23
 user=NomUsuari
 #Aquí­ haurem d'introduïr el nom d'usuari administrador del nostre router: admin, 1234, adminttd, admintde... segons el prvoeïdor.
 pass=CLAU
 #Aquí­ la clau del nostre router.
 cmd1=sh
 cmd2="adsl connection --down"
 cmd3="adsl connection --up"
 cmd4=reboot
( echo open ${Router-DSL}
 sleep 1
 echo ${user}
 sleep 1
 echo ${pass}
 sleep 1
 echo ${cmd1}
 sleep 2
 echo ${cmd2}
 sleep 2
 echo ${cmd3}
 sleep 2
 echo ${cmd4} ) | telnet
fi

Amb aquest arxiu, tindrem automatitzada la connexió al nostre router ADSL i farà un reinici de la interfí­cie DSL si aquesta no respòn.

Ara només ens faltarà modificar el crontab per què l’executi cada 15 minuts per exemple

crontab -e

*/15 * * * * /home/reset-dsl.sh

Potser per acabar de millorar-ho ens faltaria afegir que ens envii un correu electrònic un cop s’ha reiniciat per allò de tenir la estadí­stica de quantes vegades s’ha de reiniciar l’equip al dia.

 

Reiniciar Mysql automàticament quan cau

Si estàs començant a utiltizar una màquina virtual o un servidor VPS amb pocs recuros, serà habitual que en algun moment caigui el servidor MySQL i que a partir de llavors les diferents pàgines web que tinguis en el teu servidor quedin fora de servei.   He trobat un petit script que et permet “controlar” l’estat del teu servei Mysql, de manera que si el detecta “aturat”, el reinicia i t’envia un correu electrònic.

Segurament l’script seria millorable però a mi de moment m’està resultant útil i el comparteixo aquí­:

Primer de tot crearem un arxiu:

vi MonitoritzacioMysql.sh

I copiarem el següent contingut:

****
#!/bin/bash
/usr/bin/mysqladmin ping -pLATEVACONTRASSENYA| grep ‘mysqld is alive’ > /dev/null 2>&1
if [ $? != 0 ]
then
sudo /etc/init.d/apache2 restart;
sudo /etc/init.d/php-fpm restart;
sudo /etc/init.d/mysql restart;
echo MysqlReiniciat | mail -s AlertaMySQL [email protected]
fi

En aquest script estarem primer de tot validant que el servei mysqld estigui viu. Si és així­ no farà res. En cas contrari ens reiniciarà l’apache, el php i el mysql.  A més, ens enviarà un correu electrònic a la nostre bústia. Serà important que tinguem instal·lat en el nostre equip VPS la utilitat mail (apt-get install mailutils).

Un cop fet això, caldrà donar-li permisos d’execució a l’arxiu que hem creat:

chmod +x MonitoritzacioMysql.sh

I per últim, modificarem el cron del nostre equip per tal que executi aquest script cada 5 minuts:

crontab -e

*/2 * * * * root sh /root/MonitoritzacioMysql.sh

Amb això ja ho tindrem tot fet. Recomano de totes maneres, provar manualment d’aturar el servei mysql i esperar uns minuts per veure com s’executa el procès i ens avisa per correu electrònic que s’ha reiniciat el servei.  Ara només ens quedarà mirar els logs del servidor amb calma per què no es produeixin reiniciades automàtiques del sistema.

 

 

 

 

 

 

 

Canvi d’ús horari a centos

Ja m’ha passat dues vegades en els últims dies, de trobar-me una màquina amb #centos i que tingui un ús horari diferent a on estem, amb el que l’anàlisi de e logs es fa difí­cil de seguir.

Deixo aquí­ les sentències d’actualització per si em trobo per tercera vegada un cas similar:

Eliminem la configuració horària de l'equip: 

#rm -f /etc/localtime

Afegim la configuració del nostre ús horari

# ln -s /usr/share/zoneinfo/Europe/Madrid /etc/localtime

I comprovem que realment és així­:

# date
jue may 30 13:30:10 CET 2013