Menu

November 2016

/var/log/wtmp – No such file or directory

, , 0

/var/log/wtmp - No such file or directoryПривет,

Днес случайно попаднах на един сървър на който командата last не му работеше.

Грешката беше следната :

 

last: /var/log/wtmp: No such file or directory

Perhaps this file was removed by the operator to prevent logging last info.

Вероятната причината за проблема е изтрит лог файл /var/log/wtmp .

Този проблем се решава по следният начин :

touch /var/log/wtmp
chown root:utmp /var/log/wtmp
chmod 0664 /var/log/wtmp

Това е – вече командата last ще връща отговор :

dev:~# last -10
root pts/0 192.168.188.147 Fri Nov 4 15:28 still logged in

proxmox software watchdog

, , 0

Привет,

В този пост ще споделя как бързо и лесно се пуска proxmox software watchdog.

proxmox software watchdog

Идеята е следната : имаме 4 сървъра обединени в proxmox cluster. Два от тях имат hardware watchdog модул, но другите два нямат.
За да работи HA при тях е необходим watchdog.

За да се активира proxmox software watchdog е нужно да направим следното :

1. Активира се softdog модула :

echo "softdog" >> /etc/modules

2. Чрез uname -r можем да видим с коя версия на линукс ядрото сме, и да редактираме следния файл :

vim /lib/modprobe.d/blacklist_pve-kernel-4.4.21-1-pve.conf

– в моят случай е версия 4.4.21-1-pve и трябва да закоментираме реда : blacklist softdog

#blacklist softdog

3. Рестартираме сървъра и проверяваме дали работи softdog модула чрез:

pluto:~# lsmod |grep softdog
softdog 16384 1

и последно дали работи watchdog-mux сървиса :

pluto:~# systemctl status watchdog-mux.service
● watchdog-mux.service - Proxmox VE watchdog multiplexer
Loaded: loaded (/lib/systemd/system/watchdog-mux.service; static)
Active: active (running) since Tue 2016-11-01 23:11:59 EET; 2 days ago
Main PID: 1167 (watchdog-mux)
CGroup: /system.slice/watchdog-mux.service
└─1167 /usr/sbin/watchdog-mux

Nov 01 23:11:59 pluto watchdog-mux[1167]: Watchdog driver 'Software Watchdog', version 0
Nov 04 10:14:25 pluto systemd[1]: Started Proxmox VE watchdog multiplexer.

Това е!

device is already in use

, , , , 0

Здравейте,

Тази сутрин трябваше да направя live migration от ext3 към ext4 на един proxmox сървър, и в този пост искам да споделя преживяното:

device is already in use

Започнах процедурата като спазвах стъпките от https://debian-administration.org/article/643/Migrating_a_live_system_from_ext3_to_ext4_filesystem , но излезе следният проблем:

Първо при umount /dev/pve/data излезе :

umount: /var/lib/vz: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)

Използвах флаг-а -l при umount и продължих по стъпките.

При fsck.ext4 -yfD /dev/pve/data обаче възникна същия проблем :

moon:~# fsck.ext4 -yfD /dev/pve/data
e2fsck 1.42.12 (29-Aug-2014)
/dev/pve/data is in use.
e2fsck: Cannot continue, aborting.

За да разбера какво караше /dev/pve/data да е все още монтиран, трябваше да използвам командата fuser -m /dev/pve/data

И така разбрах следното :

moon:/var/lib# fuser -m /dev/pve/data
/dev/dm-2: 11657 11685 17558 22012 24655 26116 29357 34728 35034 35694 42784 46330 47645

Това бяха pid-овете на процесите задържащи /dev/pve/data .. спрях ги един по един и успях да продължа миграцията както следва :

moon:~# tune2fs -O extents,uninit_bg,dir_index /dev/pve/data
tune2fs 1.42.12 (29-Aug-2014)
moon:~# fsck.ext4 -yfD /dev/pve/data
e2fsck 1.42.12 (29-Aug-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 3A: Optimizing directories
Pass 4: Checking reference counts
Pass 5: Checking group summary information

/dev/pve/data: ***** FILE SYSTEM WAS MODIFIED *****
/dev/pve/data: 770019/482590720 files (0.3% non-contiguous), 1543788056/3860725760 blocks

Накрая монтирах на ново /dev/pve/data към /var/lib/vz и вече имах успешно мигрирана ext4 файлова система! Нито един файл не се затри през цялата операция! 🙂

Това е!

mysql select convert_tz returns null

, , , , 0

mysql select convert_tz returns nullПривет,

Днес се сблъсках с един странен проблем при конвертиране на timezone в MySQL.

Проблемът беше следния : mysql select convert_tz returns null

 

mysql> SELECT CONVERT_TZ('2016-11-01 18:00:00', 'Europe/London', 'UTC');
+-----------------------------------------------------------+
| CONVERT_TZ('2016-11-01 18:00:00', 'Europe/London', 'UTC') |
+-----------------------------------------------------------+
| NULL |
+-----------------------------------------------------------+
1 row in set (0.00 sec)

Това го дава въпреки настроената правилно timezone-а на сървъра :

mysql> SELECT @@global.time_zone, @@session.time_zone;
+--------------------+---------------------+
| @@global.time_zone | @@session.time_zone |
+--------------------+---------------------+
| SYSTEM             | SYSTEM              |
+--------------------+---------------------+
1 row in set (0.00 sec)

Вместо NULL обаче трябва да вади валидна дата и час.

Този проблем се оправя с командата : mysql_tzinfo_to_sql , или накратко така :

mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql

И вече резултата от селекта изглежда така:

mysql> SELECT CONVERT_TZ('2016-11-01 18:00:00', 'Europe/London', 'UTC');
+-----------------------------------------------------------+
| CONVERT_TZ('2016-11-01 18:00:00', 'Europe/London', 'UTC') |
+-----------------------------------------------------------+
| 2016-11-01 18:00:00 |
+-----------------------------------------------------------+
1 row in set (0.00 sec)

Това е!

Nginx reverse proxy and subdomains

, , , , 0

Привет,

Наскоро ми се наложи да търся решение за използване на Nginx като reverse proxy със субдомейни.

Nginx reverse proxy and subdomains

Идеята беше следната :

Имаме сайт : testsait.com който се намира на един сървър с nginx и wordpress блог на адрес : blog.testsait.com който се намира на друг сървър.

Целта е да направим testsait.com/blog да се отваря директно през blog.testsait.com.
Всичко това е с цел по-добро SEO, или поне нашите SEO гурута смятат така 😀 хаха.

Ето и начина по който се прави това:

Във виртуалният хост на сайта ни testsait.com се добавя следното :

location /blog/ {
rewrite ^/blog/(.*) /$1 break;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 90;
proxy_pass http://blog.testsait.com/;
proxy_redirect http://blog.testsait.com/ /blog/;
}

Този блок се добавя преди: location /

Така направено всичко ще работи, освен wp-login.php. Причината е заради location ~ \.php$ {

За това този location блок се заменя със следния :

location ~* ^((?!\/blog)(.+)\.php)$ {

fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/var/run/php5-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_max_temp_file_size 0;
client_max_body_size 32M;
fastcgi_buffer_size 128k;
fastcgi_buffers 256 4k;
fastcgi_busy_buffers_size 256k;
fastcgi_temp_file_write_size 256k;
fastcgi_read_timeout 240;
#add_header X-Robots-Tag "noindex, nofollow, nosnippet, noarchive";
fastcgi_param SCRIPT_FILENAME /var/www/testsait.com/$fastcgi_script_name;
}

Така всички php заявки ще бъват насочени към php-fpm socket-а освен /blog/.

Резултата е работещ testsait.com/blog и testsait.com/blog/wp-login.php.

Това е!