Menu

Howto

root.bg howto

Raspberry Pi Wireless 3g Router

, , 0

Здравейте,

Днес ще споделя как през уикенда намерих малко свободно време и си направих Raspberry pi wireless 3g router – или намерих приложение на едното ми излишно Pi 🙂

Raspberry Pi Wireless 3g Router

Първо ще кажа че има много по-лесни начини да имате 3G рутер – продават се сполучливи модели на Tp-link , но аз исках да си го направя сам 🙂

За целта използвах Raspberry Pi модел B+ с 5.25 волта и 2 амперово захранване , Wifi Nano USB Dongle и usb 3G модем от Mtel

Инсталирах raspbian и след това сложих 3G модема и Wifi адаптера. Уверих се че PI-то ги засича :

Още..

auth_pam: pam_authenticate failed: Authentication failure

, , , , , 0

Привет,

Искам да споделя за един проблем който ме мъчи от сигурно половин година, свързан с един saslauthd демон.

Навремето имах един стар дебиан с ISPconfig и courier-imap. След време трябваше да ъпгрейдна сървъра, като го направих на виртуалка с ubuntu 12.04 и реших да заменя courier-a с dovecot. Обаче там се объркаха едни схеми, и за да оправя положението отново върнах courier-a.

От тогава обаче всеха да се случват странни неща при опит да се изпрати мейл, неща от типа на :

 

SASL LOGIN authentication failed: authentication failure

В този си му вид лога не ми говори нищо, и за целта добавих в /etc/pam.d/smtp “debug” и почнах да дъбъгвам. И както писах в предния пост по темата реших проблема временно с рестарт на saslauthd-то.

Да обаче днес оправих проблема напълно!
За целта реших тотално да се отърва от saslauthd, и да използвам courier-authdaemon-a.
Първо направих следната промяна в /etc/postfix/sasl/smtpd.conf
Замених pwcheck_method: authdaemond вместо pwcheck_method: saslauthd
Замених authdaemond_path: /var/run/courier/authdaemon/socket вместо saslauthd_path: /var/run/saslauthd/mux

Спрях saslauthd и пуснах courier-authdaemon.
След това направих следната схема :

/etc/init.d/courier-authdaemon stop
rm -rf /var/run/courier/authdaemon/
rm -rf /var/spool/postfix/var/run/courier/authdaemon/
mkdir -p /var/spool/postfix/var/run/courier/authdaemon/
ln -s /var/spool/postfix/var/run/courier/authdaemon/ /var/run/courier/authdaemon
/etc/init.d/courier-authdaemon start
/etc/inti.d/postfix restart

И воала! Нещата придобиха дормалният си вид и всичко си проработи както трябва!

Извода, има бъг в pam модулите, в http://wiki2.dovecot.org/PasswordDatabase/PAM пишат да се използва директивата pam_maxrequests за да се избегнат подобни проблеми, но аз реших кардинално да си реша проблема.

При другите ми мейл сървъри които използват dovecot и saslauthd нямам подобни ситуации, и заради това мисля че всичко се обърка заради първоначлното инсталиране на dovecot и модулите му и след това courier.
Аз винаги съм използват howto-тата от howtoforge.com и не съм имал проблеми, но в случая мисля че сам си създадох моя 🙂

debug website’s load time with strace

, , , , 0

Хелоу,

В работата ми като системен администратор, често се налага да помагам на девелопърите в дебъгване на ситуации с бавно зареждащи уеб сайтове. Като изключим факта че сме проверили дали всичко по сървъра е наред, дали другите уеб страници на самата машина зареждат добре, а конкретния уеб сайт зарежда 10 пъти по-бавно от другите, в този случай използваме за помощ – strace.
debug website's load time with strace

Това е много полезна програма с която дебъгваме примерно index.php-то на конкретния сайт, и в лога който ще запише програмата можем да видим в timeline кога какво се стратира и зарежда и къде идва и разликата в секундите и съответно къде е проблема в кода.

Чрез командата :

 

strace -t -f -o strace.txt /usr/bin/php index.php

Ние ще направим точно това което съм написал по-горе и резултатите можем да ги прочетем после в strace.txt лога.

Резултатите са нещо от рода на :

1727 10:31:38 fcntl(4, F_SETFL, O_RDWR) = 0
1727 10:31:38 sendto(4, "GET /feed/ HTTP/1.0\r\n", 21, MSG_DONTWAIT, NULL, 0) = 21
1727 10:31:38 sendto(4, "Host: www.tips.website"..., 42, MSG_DONTWAIT, NULL, 0) = 42
1727 10:31:38 sendto(4, "\r\n", 2, MSG_DONTWAIT, NULL, 0) = 2
1727 10:31:38 poll([{fd=4, events=POLLIN|POLLPRI|POLLERR|POLLHUP}], 1, 0) = 0 (Timeout)
1727 10:31:38 poll([{fd=4, events=POLLIN|POLLERR|POLLHUP}], 1, 60000) = 1 ([{fd=4, revents=POLLIN|POLLERR|POLLHUP}])
1727 10:31:59 recvfrom(4, 0x7faf915a8b10, 8192, 64, 0, 0) = -1 ECONNRESET (Connection reset by peer)
1727 10:31:59 close(4) = 0
1727 10:31:59 socket(PF_FILE, SOCK_STREAM, 0) = 4
1727 10:31:59 fcntl(4, F_SETFL, O_RDONLY) = 0
1727 10:31:59 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
1727 10:31:59 fcntl(4, F_GETFL) = 0x2 (flags O_RDWR)
1727 10:31:59 fcntl(4, F_SETFL, O_RDWR|O_NONBLOCK) = 0
1727 10:31:59 connect(4, {sa_family=AF_FILE, path="/var/lib/mysql/mysql.sock"}, 110) = 0

От всичкия лог, най-важното за нас е разликата в секундите – 21 секунди. Тук идва и проблема – самият сайт се зареждаще за около 20-25 секунди. И в крайна сметка се оказа че, в конфигра му беше зададен грешен url към несъществуващ хостнейм (www.tips.website…), и забавянето идваше от факта че , самият сайт се опитваше да го резолвне и не успяваше.

glibc ghost bug

, , , 0

glibc ghost bugПичове,

На лице е много, ама много сериозен бъг в glibc наречен glibc ghost bug! Не съм сигурен дали вече има експлоити, но ако няма е въпрос на време да плъзнат из нета. Смята се че проблема е толкова сериозен, че са засегнати всички сървиси които са пуснати на даденият сървър с проблемен glibc.

До колкото разбрах , вече е пусната кръпка и се съветва моментално да се обнови библиотеката glibc!

За съжеление всички сървиси трябва да се рестартират след като се обнови glibc-то.

За да проверите кои сървиси са свързани с glibc библиотеките, напишете следната команда:

 

lsof | grep libc | awk '{print $1}' | sort | uniq

Пакетите за дебиан и убунту са вече обновени с последната стабилна версия на glibc. Тези за centos и redhat се очаква всеки момент да бъдат обновени по репотата си.

Повече може да се намери тук, тук и тук

Засегнати сървиси са :

  • Mailservers using reverse DNS lookups on connecting IPs (DNS Blacklisting, SPF checks, …)
  • Form submits that allow user content which results in a DNS lookup, think URLs, WordPress XML-RPC pingbacks, …
  • MySQL servers doing authentication checks based on hostnames (in MySQL privileges)
  • SSH servers that perform DNS lookups for authentication allow/deny rules

Ъпдейтвайте при първа възможност!!

Cpanel fix home permissions

, , , 0

Привет,

Днес по погрешка един скрипт смени правата на всички потребилски home директории , и поради тази причина много сайтове спряха да работят. Трябваше да се реагира бързо, защото ръчната смяна на 800 потребителя щеше да отнеме доста време.

За целта използвах следния скрипт който ми реши проблема веднага. Намерих го в този блог.

 

#!/bin/bash

echo -e "Checking ownership of /home/user \n"
for i in `ls /var/cpanel/users/`
do
if [ "$i" != "root" ]; then
chown -R $i:$i /home/$i
chown $i:nobody /home/$i/public_html /home/$i/.htpasswds
chown $i:mail /home/$i/etc /home/$i/etc/*/shadow /home/$i/etc/*/passwd
echo $i
fi
done

По този начин всичко се оправи бързо и лесно. В моя случай всички директории бяха с права на друг потребител, не root , и за целта замених root с потребителя.

Load More