madWiMAX — использование Yota в Linux

madWiMAX — реверс-инжинированный Linux драйвер для устройств доступа к сетям mobile WiMAX (802.16e), выполненных на основе чипа Samsung CMC-730. На данный момент поддерживаются следующие устройства:

  • Samsung SWC-U200
  • Samsung SWC-E100
  • Samsung SWM-S10R

madWiMAX есть в официальном репозитории debian’а.

$ aptitude install madwimax

Настройка йоты проста.

После покупки йота-модема я зарегистрировал его из-под виндовс в личном кабинете, а потом уже сунул в дебиан. Регистрация элементарна и, думаю, что даже из lynx можно было её проделать.

Говорим спасибо Александру Гордееву и остальным разработчикам за madwimax. Говорим спасибо Петру Курышеву за сборку deb пакетов и качаем отсюда http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0 два пакета:

$ wget http://peter.infosreda.com/libusb1_1.0.0-1_i386.deb
$ wget http://peter.infosreda.com/madwimax_0.1.0-1_i386.deb

и устанавливаем их:

$ dpkg -i libusb1_1.0.0-1_i386.deb
$ dpkg -i madwimax_0.1.0-1_i386.deb

«Для того, чтобы модем автоматически соединялся с сетью Yota при включении в USB разъем, потребуется раскомментировать последние две строчки (их там всего четыре) файла /etc/udev/rules.d/z60_madwimax.rules»

Настроил NAT для людей в локальной сетке. Все вздохнули облегчённо, но было замечено, что многие сайты не открываются. Спасибо http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/ за описание и разрешение проблемы:

«Пришлось добавить

iptables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -o wimax0 -j TCPMSS –clamp-mss-to-pmtu

Это правило просто отключает бит DF.»

Была засада — пропал интернет. Запустил на серваке lynx www.rambler.ru и увидел страницу йоты, где было написано про то, что «если вы видите эту страницу, то оплатите…, проверьте…, зарегистрируйте модем…, выньте и всуньте модем…».

Попробовал вынуть/всунуть — помогло. В первый раз, правда, слишком быстро вынул/всунул. Потом попробовал с пару-тройку секундным запозданием и всё заработало.

Вторая засада — при подключении к Йоте по DHCP назначаются новые йотовые DNS, которые прописываются в /etc/resolve.conf. А надо, чтобы доменные оставались, так как есть домен и второй провайдер.

Нагуглил  http://evilzipik.blogspot.com/2009/01/resolvconf-dhcp.html

Чтобы этого не происходило нужно:

в /etc/dhcp3/dhclient-enter-hooks.d/ создать пустой файл, например, nodnsupdate

сделать его исполняемым

$ chmod +x /etc/dhcp3/dhclient-enter-hooks.d/nodnsupdate

в него занести:

#!/bin/sh
make_resolv_conf(){
 :
}

И ещё. Когда запускаю madwimax -vv для поиска места с максимальным усилением сигнала, то сыпятся сообщения bulk write error. Поменял USB кабель на толстый экранированный. Эти ошибки пропали.

И ещё. Недавно переустановил на сервере debian x32 на debian amd64. Через какое-то время обнаружил, что не могу зайти в gmail почту через https. Не знаю связаны ли эти события. Уменьшил MTU на интерфейсе своей убунты до йотовских значений — 1386 байт. Почта заработала. (временно для проверки увеличил до 1387 байт — почта перестала работать) Примечательно, что под виндами спокойно вхожу в почту. Только одно предупреждающее сообщение и дальше можно работать. Видимо из-за автоматического определения размера MTU.

2010-09-10. С начала сентября 2010 года йота в ауте. Скорость мизерная. Работать невозможно. Ищу дешёвого проводного провайдера.

2010-11-02. Провайдера нашёл, но и с йотой более-менее разобрался. Запускаю:

$ madwimax -vv

и смотрю на значение CINR. Начинаю искать модемом на USB удлинителе максимальное значение CINR. Меньше пяти — плохо. Начиная с 6, 7 — более-менее. 9-10 — хорошо. Это пока максимальное значение достигнутое мной. Значение достигается поворотом модема вокруг вертикальной оси градусов на 45 от оконного стекла и сдвигом его на пару сантиметров влево — вправо около определённой точки на подоконнике.)) Если сигнал есть, но инет тормозной, то передвигаю модем в другую точку на подоконнике, где он цепляется к другой точке доступа. Есть вероятность, что через эту точку доступа инет будет более быстрым.

После испытаний и прерывания Ctrl-C запущенного madwimax -vv, необходимо переткнуть модем, чтобы модем переинициализировался.

Ссылки:

http://peter.infosreda.com/ru/2009/03/23/ubuntu-deb-madwimax-0_1_0
http://x4da.wordpress.com/articles/madwimaxiptablesdhcp/

Настройка APC UPS

Устанавливаем

$ aptitude install apcupsd

В /etc/apcupsd/apcupsd.conf правим соответствующие строчки:

UPSCABLE usb
UPSTYPE usb

Запускаем демон:

/etc/init.d/apcupsd start

apcaccess для вывода информации по UPS.

Ещё команда для теста UPS, для изменения даты смены батареи и т.п. apctest.

Работает после остановки демона apcupsd.

Проблемы:

Остановил apcupsd и дал команду apctest, а в ответ:

# apctest
 2009-12-14 12:28:11 apctest 3.14.4 (18 May 2008) debian
 Checking configuration ...
 Attached to driver: usb
 sharenet.type = DISABLE
 cable.type = USB_CABLE
You are using a USB cable type, so I'm entering USB test mode
mode.type = USB_UPS
Setting up the port ...
apctest FATAL ERROR in device.c at line 70
Unable to create UPS lock file.
If apcupsd or apctest is already running,
please stop it and run this program again.
apctest error termination completed

Запустил apcuspd и дал команду apcaccess, в ответ:

# apcaccess
Error reading status from apcupsd @ localhost:3551: Connection timed out

Остановил apcupsd и проверил:

# ps aux | grep apc
 root 2509 0.0 0.0 193356 1148 ? Ssl Dec13 0:03 /sbin/apcupsd
 root 6739 0.0 0.0 7236 848 pts/1 S+ 12:55 0:00 grep apc

Убил процесс /sbin/apcupsd:

root@deb5:/var/run# kill 2509

И всё заработало.

named.conf.options

Содержимое named.conf.options:

options {
 directory "/var/cache/bind";        //Понятно, что это кэш для запросов
 forwarders {                       //Секция для форвардинга неразрешённых
     10.0.0.1;                      //запросов. Т.е. резольвинг адресов будет
 10.0.15.1;                     //выполняться указанными здесь серверами.
 };                             //Чаще всего указываем DNS-сервера провайдера.

auth-nxdomain no; # conform to RFC1035        //Что-то отключённое. Потом посмотрим.

listen-on {
     127.0.0.1;                     //Наш DNS-сервер будет принимать запросы
     192.168.0.1;                    //только на внутренних адресах.
    };
 };

lm-sensors

Установка

# apt-get install lm-sensors

На сайте http://www.lm-sensors.org советуют использовать последний lm-sensors 3.1.1.

  • Удалил текущий lm-sensors.
  • Скачал из нестабильной ветки Debian пакет с lm-sensors 3.1.1.
  • Попробовал установить скаченный пакет dpkg -i lm-sensors*.deb
  • Обнаружилась неудовлетворённая зависимость -> libsensors4.
  • Скачал оттуда-же пакет libsensors4 и установил. В результате пакет lm-sensors заработал.
  • Запустил sensors-detect и обнаружил:
  • w83627ehf и coretemp
  • Разрешил добавить эти строки в /etc/modules.
  • Перезагрузил компутер.
  • sensors заработал.
Настройка

В большинстве случаев настройка отслеживания за температурами, скоростью вращения вентиляторов и т.д. проста.

$ sensors-detect

На все вопросы отвечаем энтером.

В конце скрипт предложит внести в /etc/modules модули для найденных системных датчиков. Согласимся. Потом можно загрузить модули без перезагрузки компутер modprobe <название модуля>. И опросим датчики командой sensors.

Если датчики показывают неправильные значения, то редактируем /etc/sensors.conf.


Переподключение к сеансу SSH

В настройках SSH поставил «не завершать сеанс при разрыве». После переподключения не знаю как присовокупиться к висящему сеансу.

В инете рекомендуют использовать screen, который позволяет использовать несколько псевдотерминалов и подключаться к ним по мере необходимости.
http://libc6.blogspot.com/2008/09/screen-terminal.html

Попробую использовать его вместо bash, как оболочку по умолчанию для ssh-сеансов.

Как настроить автоматический запуск screen при входе по ssh

Достало постоянно вводить screen -dR при входе на удалённую машину. Погуглив нашёл простое решение. В конце ~/.bashrc дописать:

 if [ -z "$STY" ]; then
 exec screen -dR
 fi

У меня чуть более продвинутый вариант 🙂

В конец .bashrc надо добавить

if [ "$SSH_TTY" ]; then
 if [ ! "$STY" ]; then
  CHOICE=`SCREEN/choose`
  if [ -z "$CHOICE" ];
  then
   exec screen
  else
   exec screen -dr $CHOICE
  fi
 fi
fi

и создать файл ~/SCREEN/choose:

#!/bin/bash
USERNAME=`whoami`
i=0
declare -ax SCREENS
SOCKETS=`find /var/run/screen/S-$USERNAME -type p`
if [ -z "$SOCKETS" ];
then
exit 0
fi
for S in $SOCKETS
do
((i=$i+1))
S=`basename $S`
SCREENS[$i]=`screen -ls | grep $S | perl -e '$s=<>; $s =~ s/^\\t(.*)\s/$1/; $s =~ s/\s/_/g; print $s'`
done
MENU=""
for ((j=1; j do
MENU="$MENU $j ${SCREENS[$j]}"
done
WHICH=`dialog --stdout --menu Select: 0 0 0 $MENU`
echo ${SCREENS[$WHICH]} | sed -e 's/_(.*)$//'

При логине будет предлагаться меню со списком имеющихся сессий screen, можно выбрать нужную либо создать новую. Если запущенных screen’ов нет, автоматически запустится новая сессия.

Единственная (вроде бы) зависимость — нужно поставить dialog.

Ссылки:
http://www.truediamon.ru/content/kak-nastroit-avtomaticheskij-zapusk-screen-pri-vhode-po-ssh

Tar

Архивирование всей папки folder без сжатия:

$ tar -cf archive.tar folder/

Архивирование всей папки folder со сжатием gzip:

$ tar -zcvf archive.tar.gz folder/

Архивирование всей папки folder со сжатием bzip2:

$ tar -jcvf archive.tar.bz2 folder/

 

Автоматическая перезагрузка Linux при kernel panic, перегрузке CPU или системном сбое

If you are a system administrator, you have probably wondered at least once ohw to configure your Linux server to automatically reboot itself if it crashes, is going through a mass CPU overload, e.g. the server load average “hits the sky”.

I just learned from a nice article found here that there is a kernel variable which when enabled takes care to automatically restart a crashed server with the terrible Kernel Panic message we all know.

The variable I’m taking about is kernel.panic for instance kernel.panic = 20 would instruct your GNU Linux kernel to automatically reboot if it experiences a kernel panic system crash within a time limit of 20 seconds.

To start using the auto-reboot linux capabilities on a kernel panic occurance just set the variable to /etc/sysctl.conf

debian-server:~# echo 'kernel.panic = 20' >> /etc/sysctl.conf

Now we will also have to enable the variable to start being use on the system, so execute:

debian-server:~# sysctl -p

There you go automatic system reboots on kernel panics is now on.
Now to further assure yourself the linux server you’re responsible of will automatically restart itself on a emergency situation like a system overload I suggest you check Watchdog

You might consider checking out this auto reboot tutorial which explains in simple words how watchdog is installed and configured.

On Debian installing and maintaining watchdog is really simple and comes to installing and enabling the watchdog system service, right afteryou made two changes in it’s configuration file/etc/watchdog.conf

To do so execute:

debian-server:~# apt-get install watchdog
debian-server:~# echo "file = /var/log/messages" >> /etc/watchdog.conf
debian-server:~# echo "watchdog-device = /dev/watchdog" >> /etc/watchdog.conf

Well that should be it, you might also need to load some kernel module to monitor your watchdog.

On my system the kernel modules related to watchdog are located in:

/lib/modules/2.6.26-2-amd64/kernel/drivers/watchdog/
If not then you should certainly try the software watchdog linux kernel module called softdog , to do so issue:

debian-server:~# /sbin/modprobe softdog

It’s best if you load the module while the softdog daemon is disabled.
If you consider auto loadig the softdog software watchdog kernel driver you should exec:

debian-server:~# echo 'softdog' >> /etc/modules

That should be all your automatic system reboots should be now on! 🙂

Экспорт или импорт сертификата PKCS#12

Файлы PKCS#12 используются в разных приложениях типа MS IIS. Они часто имеют расширение .pfx.

# создать файл, содержащий ключ и самоподписной сертификат
openssl req \
  -x509 -nodes -days 365 \
  -newkey rsa:1024 -keyout mycert.pem -out mycert.pem

# экспортировать mycert.pem как файл PKCS#12, mycert.pfx
openssl pkcs12 -export \
  -out mycert.pfx -in mycert.pem \
  -name "My Certificate"

Превратить pfx в pem:

# export certificate and passphrase-less key
openssl pkcs12 -in mycert.pfx -out mycert.pem -nodes

# same as above, but you’ll be prompted for a passphrase for
# the private key
openssl pkcs12 -in mycert.pfx -out mycert.pem