Nagios NRPE, мониторинг Windows-систем

В тему мониторинга доступности сервисов, серверов и т.д.
Windows обычно тоже мониторить надо! Так вот... для этого есть хорошая штука - NRPE_NT. Версия с sf.net лишена, конечно, плагинов. Их можно взять с Nagios Exchange, а можно скачать версию сразу с плагинами.

Чем это, на мой взгляд, лучше, чем удаленный мониторинг того же места на дисках через chech_disk_smb_user? Да, по-моему, это несколько безопаснее. Не надо указывать в конфигурационных файлах nagios паролей, есть поддержка ssl.

Для начала на самом nagios-сервере нужно установить nrpe-плагин:

aptitude install nagios-plugin-nrpe

На машине, которую нужно наблюдать, устанавливаем winrpe...

Редактируем конфигурационный файл в C:\Program Files\Nagios NRPE Agent\bin\nrpe.conf, задаем там фильтр по разрешенным хостам и команды плагинов. По-умолчанию там указаны проверка места на дисках, загрузки процессора и памяти, а также проверки, запущены ли некоторые сервисы и нет ли определнных записей в eventlog. Исправляем их по-необходимости, добавляем новые и т.д. Стартуем сервис nrpe_nt:

sc start nrpe_nt

Теперь нужно добавить сервисы в конфигурационный файл nagios (пример):
/etc/nagios/services.cfg:

define service{
        use                             generic-service         ; Name of service template to use
        
        host_name                       dpsrv
        service_description             Disk Space - C:\
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              3
        normal_check_interval           5
        retry_check_interval            1
        contact_groups                  dnepr-admins
        notification_interval           240
        notification_period             24x7
        notification_options            c,r
        check_command                   check_nrpe_1arg!pdm_disk_c
}       

Перезапускаем nagios...

# /etc/init.d/nagios/restart

Наслаждаемся!

Продолжение темы GTD

Как я сказал раньше, я добавил в Thinking Rock новый критерий для дел, который определял, лень мне это делать прямо сейчас или нет.

В общем-то разнесение по разным Action-Screen-ам запланированных на сегодня дел, и дел, которые надо 'Do ASAP', + фильр по "Лени" как-то еще более ленивым меня сделало. Точнее выходит, что что "Важно и срочно" это не важный показатель на самом деле, потому что дела с таким приоритетом висят у меня в списке уже вторую неделю. И список в течение этих недель не уменьшился не на пункт. Так что, есть ощущение, что лучше сделать как раньше - все в одном месте.

А не посоветуете ли чего-то действенного по самодисциплине? )

Первое правило сисадмина

Необходимо полностью раскулачить всех пользователей, отобрав у них все, что у них было, то есть - административные права и доступ куда угодно. Только лимитированный доступ, по талончикам. Даже если это не ваша контора и вы в ней постоянно не работаете. Да, обговаривайте с руководством такой шаг. Да, они должны понимать что до конца садятся на иглу саппорта/админа, но если они действительно не хотят иметь лишних сбоев - это единственный шаг. )

Навеяно:
Контора без сисадмина, у всех по-дефолту все с правами админа (единственного пользователя системы), грохнули себе принтер (ну, как объект в системе) и теперь не могут восстановить. Удачно, вовремя очень.

Я бы хотел

1. Чайник с электросвистком
2. Самопросыхающие внутри ботинки
3. Специальные сменные стельки для ботинок наподобие прокладок для женщин
4. Удобную подставку для ноутбука
5. Телефон, который бы умел одновременно работать с двумя симками (именно одновременно), и при этом умел EDGE и яву, и в общем не отставал по функциональности от SE K790i
6. Микроволновку.
7. Сетевое хранилище на терабайт.
8. Две 9-ячейковые батареи для своего ноута.
9. Электрический нагреватель для воды в ванной. =)
10. Будильник, который бы не только будил, но и делал меня не сонным.
11. Безлимитный, толстый и беспроводной интернет с покрытием по всему городу с небольшой задержкой.

Все. Вроде-бы все материальное, что вот так вот за 15 минут взбрело в голову.

Я открыл. Но в текстовом редакторе удобнее!

< Map> Как редактировать файл с правами админа с помощью команды в командной строке?
< Miha_hard> чтобтя
< Miha_hard> sudo vi filename
<@kav> sudo joe file.txt
< Miha_hard> sudo nano filename

< Map> vi=view
<@kav> или sudo nano file.txt
<+EAFF00FFFF> Miha_hard: нафига ты человеку ви рекомендуешь? он же триста раз тебя проклянет за это
< Map> ога)
<+EAFF00FFFF> Map: пользуй редактор nano
< stasikos> vim надо рекомендовать
< arku|work> unix-way ниипаца (:
< Miha_hard> в данном случае vi = редактор
< Map> пофик
< Map> я приду сюад с линя
-!- Map [user@ip-10-50-176-46.is74.loc] has quit [""]
< Miha_hard> а что он там подставит его дела
< BlackBeard> может лутьше sudo mc
< stasikos> "я приду сюда с линя!!!" )
< Miha_hard> чем лучше то
< arku|work> mcedit тогда уже
<+EAFF00FFFF> BlackBeard: mcedit
< arku|work> да и то nano не сравним ни с чем.. для меня по крайней мере
< Miha_hard> чтоб потом на .mc права менять? :)
< arku|work> разве что с ее
< BlackBeard> ну там и редактор с подсветкой синтаксиса
< Miha_hard> что нано что ее - у обоих нет "найти и заменить", а без этого это не радакторы.
<@kav> линь это вроде такая речная рыбка зелёного цвета
< arku|work> есть перейти к строке, есть поиск. Меня устраивает в большинстве случаев. А вообще ты прав..
< arku|work> найти и заменить неплохо бы.. а что в консоли умеет это?
< stasikos> vim?
< Miha_hard> BlackBeard syntax on в .vimrc дописать не судьба?
< arku|work> не хочу vi(m) :)
< arku|work> и хотя пользоваться умею - меня он напрягает %(
< Miha_hard> arku|work джое умеет
< BlackBeard> не, не судьба:)
< Wolong> arku|work: replace oldstring newstring < oldfile > newfile
< stasikos> %s/fu.k/*censored*/g, ради бога, даж с регекспами
< arku|work> Wolong, я уже joe поставил :)
< Wolong> arku|work: emacs ставь
< stasikos> а joe это для емаксеров
< Wolong> joe не тру
* Miha_hard не боится проклятий EAFF00FFFF :) ваще..
< stasikos> гм. "найти и заменить" можно и sedом
< Wolong> replace!
< stasikos> No manual entry for replace
< arku|work> stasikos, можно и ваще весь файл перепечатать с замной нужного
< Wolong> зачем sed'ы, перлы, вимы, итд
< BlackBeard> sedom насколько я помню это идеал
< stasikos> The program 'replace' is currently not installed. You can install it by typing:
< stasikos> sudo apt-get install mysql-server-5.0
< stasikos> что такое replace?
< Wolong> replace - a string-replacement utility
< stasikos> Wolong: это непереносимо. а sed есть везде. намек ясен? )
< Wolong> кстате, он похоже реально входит в мускуль)
< Wolong> вот уж не думал
< Miha_hard> Wolong фрюха? :)
< Wolong> да
< Miha_hard> она бам в бейс
< Miha_hard> *там
<+EAFF00FFFF> Miha_hard: чтоб тебя глисты сожрали! полегчало?
-!- map [~map@ip-10-50-176-139.is74.loc] has joined #linux
< map> всем привет
< Miha_hard> EAFF00FFFF кто сказал что мне было тяжело? :))
< map> а если надо б открыть в текстовом редакторе
< Miha_hard> ээ..
< Miha_hard> а о чем тебе тут писали 17-ть человек
< map> это вы про консоль
< map> я открыл
< map> но в текстовом редакторе удобнее

О тайм-менеджменте

Вот уже месяца два пытаюсь натянуть на себя систему GTD, правда не в бумажном, а в электронном виде, с помощью такой софтины как ThinkingRock. Заточена она изначально под оригинальную методику Д. Карра, (использует ее основной поток обработки "дел, которые надо сделать") но несколько гибче, посему, моя эволюция в ней и завершающий итог наблюдений приведена ниже.

Итак, как начался мой путь к этому:
1. Книга Т. Лимончелли "Тайм-менеджмент для системных администраторов".
2. Дэвид Аллен, "Get Things Done".
3. Статья про Thinking Rock в чьем-то блоге (к сожалению, не помню где).

Каким он был:
1. Сначала я вытащил все To-Do списки из Evolution. Да, раньше я хранил их там. До этого - в voo2doo.com. Еще раньше - в консольном, написаном на bash приложении.
2. После этого я кое-как их обработал.
3. Я проработал в таком режиме неделю, изредка добавляя новые "дела" в список.
4. Потом я научился выбрасывать дела, которые делать прямо сейчас лениво, в список Someday/Maybe.
5. Я подумал, что там они будут валяться вечно и стал ставить в них Tickle Date на начало следующей недели, чтобы обрабатывать их каждый понедельник.
6. Когда я все-таки понял, что их стало около сотни, я утомился и стал ставить эту дату на начало очередного месяца.
7. Потом где-то в форуме Thinking Rock прочел, что можно создавать отдельные узкоспециализированные Action Screens с отдельными удобными фильтрами.
8. Это некоторое время работало, и я тут же почитал и подумал про приоритеты. Автоматом все разделилось на 5 приоритетов - "Срочно и важно", "Важно и не срочно", "не важно и срочно", "не важно,не срочно" и "может не делать вообще?". Постепенно я заметил что в день бывает 2-3 "Срочных и важных дела", еще 5-6 важных или срочных. Остальные (а их в среднем падало около 60) были "может вообще не делать?". В общем, мне снова надоело их переносить изо дня в день, так как они мешались на Action-Screen, который назывался "Сегодня".
9. И тогда я просветлел. Для задачи есть еще один критерий - "Энергия". И вместо "ментальных-физических" градаций я записал просто две: "Лень" и "None". И вот, в фильтре Today "Лень" у меня не отображается и список получается чертовски коротким.

А теперь о главном. Выводы, мысли...
1. Никакая система тайм-менеджмента или управления делами, никакие списки приоритетов и т.д. не помогут вам сделать больше чем вы хотите. ) Она попросту не мотивирует. Единственное что она помогает делать - это забывать о том что ты не делаешь в данный момент. Уставать и правда стал меньше.
2. Если у вас очень много незавершенных дел - это плохо. Это мешает работе системы. Выбирать задачи из длинных списков очень и очень трудно. Так что их или не накапливать (делать сразу), или выбрасывать в мусор.
3. Что могло бы исправить 2-й пункт списка: если бы там была возможность устанавливать взаимосвязи между задачами вида "не может быть сделано раньше чем (другая задача)". Это могло бы просто исключить появление 50% задач в списке текущих дел, которые надо "Прямо сейчас сделать", так как они относятся к проектам и их этапам. Да, там есть похожая возможность, но она слишком замутно и неинтуитивно сделана. В общем, если есть что-то лучше, жду идей.

За сим все. )

Как открывать ссылки из URxvt в браузере при помощи мыши?

в ~/.Xdefaults:

URxvt.perl-ext-common:  default,matcher
URxvt.urlLauncher: firefox
URxvt.matcher.button: 1
URxvt.colorUL:   #86a2be

Ссылки будут голубыми и открываться по нажатию левой кнопки мышки в firefox. )



* via nion's blog

Как создать резервную копию одной таблицы Firebird SQL Server?

Существует готовая удобная утилитка: FBExport.

В ее cli-версии это делается примерно так:

 > fbexport -d d:\Bases\mydb.fdb -P masterkey -V MYTABLE -Si -F MYTABLE-backup.sql

Восстановить назад из командной строки, если бекап был произведен таким образом можно так:

 
> fbexport -d d:\Bases\mydb.fdb -P masterkey -X -Q "delete from MYTABLE"
> fbexport -d d:\Bases\mydb.fdb -P masterkey -X -F MYTABLE-backup.sql

Вообще ключ -X позволяет выполнять произвольный SQL скрипт на базе данных. )

Для обычных людей о принципе TIMTOWTDI на примере...

* ramok сегодня узнал что американцы едят бананы открывая его у кочерыжки
< Zeks-Zeks> рамок
< abp> чорт. я тоже
< Zeks-Zeks> я вообще то тоже )
<@ramok> вам пора иммигрировать.. Ж:-D
< stasikos> не знал о таком способе
< stasikos> TIMTOWTDI в действии
* Zeks-Zeks не представляет как открывать банан с другой стороны
< Zeks-Zeks> обязательно попробую)
< _maniac_> я тоже встречал пару человек, что ели так

На тему потерь пакетов и прочей мути в Ethernet

Оказывается, для свича с номинальным питанием 7V, если его питать по витой паре, нужно подавать не меньше 12V, если до него 100 метров или около того. А вообще надо бы попробовать купить 14V блок питания.

А все почему? Сегодня все началось с 16% packet loss и закончилось 100%. После поднятия напряжения с 9V до 12V - 2%. Красота, все счастливы.

VMWare 6.5 порадовала

Кажется, virtualbox ее не догонит никогда. Мало того что она ощутимо быстрее, теперь она тоже может интегрировать приложения гостевой системы в хостовую ОС. Ну и поддержка DirectX 9.0c внутри виртуальной машины с аппаратным ускорением - тоже немаловажно. В общем, я в восторге.

Intel D845GVFN, мир праху твоему!

Проводил сегодня на тот свет вторую за минувшие полгода материнку одними и теми же симптомами - после отключений электроэнергии не стартует вообще. (Нет реакции на кнопку Power). Какая-то серийность. Думается, что и починить можно было бы, но хз как. =)

Passed

Exam Name:  (640-802) Cisco Certified Network Associate 
Exam Date:  29.09.08 
Grade:          Passed

Создание snapshot с виртуальной машины VMWare из командной строки

Оказывается, в комплект входит утилита vmrun, которая позволяет производить множество действий с виртуальными машинами из командной строки.

# vmrun list
Total running VMs: 1
/home/vmware/Virtual Machines/Win2k3-DC/WinSrv2k3EE.vmx

#vmrun snapshot "/home/vmware/Virtual Machines/Win2k3-DC/WinSrv2k3EE.vmx"

#

В маршрутке

IRC-шное

Вот такая штука ездит по улицам и давит спамеров. Наверное.

Ubuntu

Подобно тому как некоторые люди в френдленте стали пользоваться Debian, я стал пользоваться Ubuntu.
Все началось с покупки ноутбука Dell Vostro 1400, на который ради интереса был установлен Ubuntu 8.04 Hardy Heron. В общем-то, полет нормальный. Все железо поддерживается из коробки, а что еще нужно? Suspend и Hibernate не вызывают нареканий, а рабочая среда, почти аналогичная debian позволяет не "переучиваться". )

В целом всем доволен, чего и вам желаю. )

Пришлось, конечно, причесать немного систему, но в основном это касается только приложений. Установил более привычные psi и amarok, заменил gnome-terminal на более быстрый rxvt, поставил vlc вместо totem, opera вместо firefox.

Generic IEEE 1284.4 Printing Support Driver

Иногда вместо долгого, нудного и безуспешного поиска этого драйвера помогает выбирать не dot4.inf, а usbprint.inf при втыкании кабеля в компьютер. Недавно столкнулся. )

Firebird SQL Server Classic и NOD32

Забавно, но попытавшись перейти на поддерживающую SMP архитектуру Classic Server, ни один клиент не мог подключиться к серверу, а в лог Firebird сыпались ошибки:
INET/inet_error: select in packet_receive errno = 10038

Виной оказался NOD32 IMON. И его мало просто отключить, нужно обязательно добавить исключение для fb_inet_server.exe из проверки. Это решает проблему.

Есть и другие причины такой проблемы:
http://www.firebirdfaq.org/faq4/

GPG

В связи с тотальной тягой на jabber, появилась перспектива легко и удобно прикрутить GPG к клиентам XMPP, да и вообще...

посему вот мой публичный ключ для jabber: 05622768
Key fingerprint = EE09 64DC 3402 480A BDDE A7A8 6651 D5B3 0562 2768

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.6 (GNU/Linux)

mQGiBEh8rDwRBADVrDqvfjV/67DpedPiRCXjPvPUc80/a/W094MNbFD1fus67U5I
vJRSv2wBkaOh8nxEgq2FLaZKSDfW11knK9niSlgP4pvlWXaC/nwnbR213xNl9qcd
QthvryCDJOxR5PEEmTEKxVEyNuQCQqOImAb2tOvdejAIQ/3/O9tbmaqsiwCgxnN3
iLL0gJNXg43Cn9du4Zwlpl8EAMr4dKOXaCCOCKyUZ0Ve4Rxw7lQOUfhG9UoZoWsG
hd1QZ/Msvxl2IUBfNxk7/FKSgtZx3Ml0Wfpm8jpnY7hk2JhZn5LwByxwWDkfL1JK
cuSNIlqcZWhmQoNrSoT0pSGjtogGMShoDYMV7o+ZKl7BNjfJ01P+zBwNfU9h9iok
noreBACe45hRF+42r+xc72TQ41/PmofjA8J2KgXBmdyTKwDMqYuFqb8DJUI2DSRh
ZpzxSziCYPL06jICYN5eeiSkLwvkF+ytzJBrAD3QsXBoACEW3ELPhHu7msZ/00qX
un9dcqH4Y6umKgV3diKl1SqlqeYHYC+412BhErSJNE3GrZE9+rQxU3RhbmlzbGF2
IEtvZ3V0IChmb3IgamFiYmVyKSA8c3Rhc2lrb3NAZ21haWwuY29tPohmBBMRAgAm
BQJIfKw8AhsDBQkDwmcABgsJCAcDAgQVAggDBBYCAwECHgECF4AACgkQZlHVswVi
J2jiEQCbB6w2KloJT0RANhgs4pGCI4vsykUAn1cU0bt8YXlO/qxlIbQ6y6GZ8AoP
uQINBEh8rEgQCACzujbOAf2ERFbyTZ+PVUgwxcPNsBd3zM127APQ76V3ca4uf/ws
icUGaJ080TUVo2zyWdW1MEWnXWwQD92RJxZd6AgCfw/Vlx4RTcTvbBbAUxFfrAcn
0NxzzPUkOhfjsHfru2jklGM7VF56mF1ulPwhw/EDbPGG51V/1uguK9fbEyhLE1o8
rwGS1BQTg80W2KMUmO1NqgIgPfXBKgLdMI8Jlic6iZpWzMefugdhP0QHpVX2b8aa
DWaMCV5g5rpFcvESBjQ+ti9qIi9TOTXYIiZsU6z+h5fVgX61zWjgB2YLgY56ZYjF
QYvQCv/eEmG1XsRAwWKb185jiZxOK/k6HZvzAAMGB/4hIIP4w2suhdFR8n4DuWxp
cfV6WhmqndVKGUOhlhbh3vSplZM83JS8dXQZfHAjkVqx1EHKuXVSzYYTOAB11H1E
fnb7NCgw4/j9OaqGKfCeLRcmYrgRVtsUP5wHJVyyq8SuyWWAXN6xkXN5UkdujrUP
EzR2uvF0xTPKM4RBfdMEyTwlnlcXxYCs6r7hIdbMLlUnozQzwM+se/P7Uxcdtx9Q
Cg8WtvILATlYfcohLn4RdJzx9zjS9mygVTmrKOvVEoRyMWDmJzWOY3/jmrnEtj4H
tSs0h5eD5XUPVH4ZTIoAz4AyCeq3Ne7vmwbjbBh4h92SL9h90Dp3obqznLGUMxsT
iE8EGBECAA8FAkh8rEgCGwwFCQPCZwAACgkQZlHVswViJ2jPAQCfRbH3P4kV1fQo
Igrd+CpZ6HV4MwwAn23gtdc2UtE5t7LcaFrcEdgrhz/g
=GLP/
-----END PGP PUBLIC KEY BLOCK-----


Но вот призывам к юзерам ICQ из моего контакт-листа, имеющим jabber, добавить мой JID и юзать его вместо UIN что-то мало кто внемлет. )

Wtf debian-sys-maint?

Вы переносили базы mysql в debian из другой опрерационной системы или повредили базу с названием "mysql", или имели счастье установить ее заново? ) Поздравляю, возможно у вас теперь появилась такая вот проблема:

debatest:~# /etc/init.d/mysql restart
Stopping MySQL database server: mysqld.
Starting MySQL database server: mysqld.
Checking for corrupt, not cleanly closed and upgrade needing tables..
/usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'
debatest:~# /usr/bin/mysqladmin: connect to server at 'localhost' failed
error: 'Access denied for user 'debian-sys-maint'@'localhost' (using password: YES)'

Как это исправить? И что это вообще за пользователь такой?
Итак, открываем /etc/mysql/debian.cnf
находим в нем строку password, запоминаем - это пароль пользователя debian-sys-maint, нужного для запуска хотя-бы проверки таблиц при старте сервера.
Заходим в клиента mysql и выполняем два запроса:


GRANT RELOAD, SHUTDOWN, PROCESS, SHOW DATABASES, SUPER, LOCK TABLES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '-- тут пишем его пароль --';

GRANT ALL PRIVILEGES ON *.* TO 'debian-sys-maint'@'localhost' IDENTIFIED BY '-- тут пишем его пароль --' WITH GRANT OPTION;


После этого ошибка исправляется и мы плывем дальше. )

Убрать мусор в history, который добавляет mc

После применения предыдущего типса про "вечную" историю команд в bash, пользователи mc находят мусор в своих файлах истории. Мусором туда гадит mc.
Этот мусор выглядит примерно так:

  414  mc
  415   PROMPT_COMMAND='pwd>&7;kill -STOP $$'
  416   cd "`printf "%b" '\0057home\0057stasikos\0057video\0057FLV\0057MOBILE'`"
  417   cd "`printf "%b" '\0057home\0057stasikos'`"

Единственное избавление от этого - заигнорить те строки, которые он туда добавляет:
(в .bashrc)

export HISTIGNORE="&:ls:[bf]g:exit: cd \"\`*: PROMPT_COMMAND=?*?"

via коммент у Tigra.info

P.S. (UPD) а еще там же, у тигро.инфо, есть намного более красивое решение

export HISTCONTROL=ignoreboth

которое можно добавить как в .bashrc, так и в bashrc для mc, который находится в ~/.mc/bashrc. Это аналог "ignorespace + ignoredups", который не дает задваивать команды в history и не добавляет туда команды, начинающиеся с пробела.

Кстати, отсюда выплывает еще один типс - при включении этой опции в своем ~/.bashrc, можно намеренно поставить пробел перед командой и она не сохранится в истории. Вдруг она конфиденциальна. )

Google Talk и Psi 0.11

Официальный HOWTO на psi-wiki не нашел, так что вот. ) Имхо, просто нужно выставить настройки на вкладке Connection как на скрине. Ну и jid - user@gmail.com, или какой там у вас e-mail.

P.S. Интерфейс меняется от версии к версии.

О перезаписи заголовков писем в exim4

Находим в конфиге два слова: "begin rewrite"
Добавляем туда строки:
<старый адрес> <новый адрес> [<флаги>]

Где <флаги> - указания, что перезаписывать. Если не указать, перезаписано будет все.
F - адрес в envelope-from
f - From:
r - Reply-To:
s - Sender:

Остальные флаги.

Моя последняя лажа. )

Решил написать о своей недавней "лаже", не принесшей никаких неприятностей, кроме бессонной ночи.

Итак, все началось с идеи оптимизировать свой /, избавившись от фрагментации файлов. В случае ext3, да и вообще linux - единственный эффективный способ - забекапить все файлы, создать ФС заново и восстановить файлы на старое место.
А для проверки фрагментации можно использовать команду e2fsck. Общеизвестно, что запускать эту команду на смонтированной фс не стоит. Но, зная это, я все равно запустил. ) Спохватившись после слов "recovering journal", я ткнул Ctrl-C (может быть, это добавило некоторое удовольствие мне в последствии, кто знает). Это было моей первой ошибкой. )
В общем, решив продолжить дело, я взял рядом лежащий диск с Ubuntu, загрузился и сделал fsck еще раз, исправляя ошибки. Фрагментация оказалась на уровне 2.2%, что не так много-то в общем...
После чего, воспользовавшись tar, я полностью сбекапил / в tar.gz, сделал mke2fs -J /dev/hda1 и полез распаковывать tar.gz со старой корневой системой. И вот как-то незаладилось. Архив был объемом порядка 2ГБ, а распаковывалось (и без сообщений об ошибках!) всего около 380 мегабайт. Долгая ругань с товарищами с #linux кончилась тем, что я запустил cpio с очень подробными опциями, и оказалось что все заканчивается на забитых нулями блоках. Я все-таки смог пропустить их, используя dd, и скармливая поток через пайп тому же cpio. Теперь, вроде-бы, распаковалось все и я даже смог загрузиться.
В чем же была моя вторая ошибка? Да элементарная - я не проверил созданную копию. )
Ну далее дело оказалось не очень хитрым - загрузился в новую систему, заметил, что часть библиотек и бинарников, в общем-то, отсутствует, и повреждена. Помог debsums - он показал, как и то чего нет, так и то что повредилось. aptitude reinstall восстановил все поврежденные файлы и система стала рабочей. Я же запомнил эти уроки, надеюсь, на всю жизнь.

Листинг имен файлов по маске горячей клавишей в bash

как-то захотелось просмотреть абстрактный jpeg из домашнего каталога программой display.

Ну, как обычно, тыкаю

$ display <tab>

И понимаю, что что-то тут не так, и выбирать из 200-300 файлов любой жпег не очень-то удобно.

Роемся в man bash. )

$ display *.jpg<Esc-g> 

(или Alt-g, или Ctrl-x, g - для просто списка без дополнения)

Нажатием Ctrl-x * можо и вовсе вместо табкомплита поместить все имена файлов по маске в командную строку.

Target filesystem doesn't have sbin/init

Первое, что стоит проверить в этой ситуации - это правильность параметра root= в загрузчике.
Второе - имеется ли /sbin/init в системе вообще.
Все остальное - потом.

(навеяно попытками поставить usplash|uswsusp в Debian Sid, в процессе пробы pm-utils)

Диаграммы сетей, фотки стоек...

Интересный ресурс

Можно просто пооценивать, можно поразглядывать. )

Получить статистику ping без завершения работы команды

Обычно, если не указывать значение параметра -c, ping посылает icmp echo до тех пор, пока не будет завершен, например, с помощью Ctrl-C:

0):stasikos@zombie:~$ ping ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
64 bytes from ya.ru (213.180.204.8): icmp_seq=1 ttl=57 time=760 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=2 ttl=57 time=703 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=4 ttl=57 time=2391 ms
64 bytes from ya.ru (213.180.204.8): icmp_seq=5 ttl=57 time=1465 ms

--- ya.ru ping statistics ---
6 packets transmitted, 4 received, 33% packet loss, time 5399ms
rtt min/avg/max/mdev = 703.354/1329.923/2391.067/682.176 ms, pipe 3

Но однажды мне захотелось странного. Поставить ping с интервалом поболее, да на долгое время, чтобы оценить этот самый packet loss в больших масштабах. Ну и смотреть статистику, не тыкая каждый раз ctrl-c и не перезапуская его снова.


"Shorter current statistics can be obtained without termination of process with signal SIGQUIT." - гласит man ping. Посему...

0):stasikos@zombie:~$ ping -q -i 2 ya.ru
PING ya.ru (213.180.204.8) 56(84) bytes of data.
(^Z)
[1]+  Stopped                 ping -q -i 2 ya.ru
1):stasikos@zombie:~$ bg %1
[1]+ ping -q -i 2 ya.ru &
1):stasikos@zombie:~$ kill -QUIT %1
6/2 packets, 66% loss, min/avg/ewma/max = 609.963/740.967/839.220/871.972 ms

Опцию q я указал, чтобы строки, которые выводит ping, не мешали работе в шелле, пока ping работает в фоне.

Kак узнать или изменить свой uid в linux

UID - это уникальный в пределах системы идентификатор пользователя. Представляет собой целое число.


Узнать его можно многими способами:

$ id 
uid=1000(stasikos) gid=1000(stasikos) группы=8(mail),20(dialout),24(cdrom),25(floppy),29(audio),44(video),
46(plugdev),1000(stasikos)
s

uid=1000 дает нам полное знание о собственном uid ).

$ id root
uid=0(root) gid=0(root) группы=0(root)

эта же команда дает нам возможность узнать и чей-то еще uid.

UID = `id -u`

В скрипте значение только текущего uid можно получать именно таким способом.


Кроме того, uid хранится в /etc/passwd:

$ getent passwd | grep stasikos
stasikos:x:1000:1000:Stanislav V. Kogut,,,:/home/stasikos:/bin/bash

Для изменения uid пользователя нужно воспользоваться командой usermod:

# usermod -u 1099 test

Но если все-таки uid пользователя в системе изменился вручную через редактирование /etc/passwd, это можно исправить, сделав пользователя владельцем его старых файлов и каталогов, которые ранее принадлежали этому пользователю, станут чужими, поэтому их нужно будет передать ему снова:

# find / -uid $OLD_UID -exec chown $username {} \;

Впрочем, эта команда может спасти и в случае, если пользователь владеет файлами за пределами своего домашнего каталога.


Задать uid при создании пользователя можно, указав ключ --uid для команды adduser.


P.S. А нафига это все? А это так, чтобы посмотреть, часто ли этот вопрос кого-то интересует.

"Обрез" из флешки

Статья с пошаговыми инструкциями

Опять GRUB и двойная загрузка

Давеча вопрос задали: на одной машине с Dual Boot Linux/Windows XP произошло странное. Вдруг ни с того, ни с сего выбор загрузки Windows XP заканчивался мертвым повисанием. Linux так же, как и раньше, загружался без проблем. Fixboot+Fixmbr с выносом Grub совершенно ничем не помогал - теперь оно висло при самой загрузке Windows.
Как оказалось, лечится это проще простого. )
Нужно было опять переключить в настройках BIOS жесткий диск из режима Auto в Large.
С чем это связано - хз, думаю как-то коряво GRUB при установке в другом режиме работает с секторами.

Vim и экономия времени

Если вы еще не пользуетесь Vim, эта статья может убедить вас делать это )

via Полезные советы по Linux

Debian-Way установка Google Earth

Казалось бы, можно как и предлагает Google, установить это приложение прямо из GoogleEarthLinux.bin, но это не отражает правильного поведения в случае Debian-Like дистрибутивов. Во-первых, это приведет к установке в систему файлов, не отслеживаемых пакетным менеджером, во-вторых это может быть неудобным, если вам хочется установить это приложение на много однородных систем и регулярно обновлять его. В-третьих, для установки этого приложения в Debian есть специальный способ.


Итак, что же надо сделать, чтобы установить Google Earth?

1. Необходимо установить утилиту для создания пакетов .deb из его инсталлятора:

$ sudo aptitude install googleearth-package

2. Необходимо скачать оригинальный .bin дистрибутив с google.com:
Перейти на страницу загрузки

3. А теперь надо натравить (1) на (2)!

$ make-googleearth-package --file /tmp/GoogleEarthInstaller.bin

Впрочем, можно попробовать и пропустить шаг 2 - утилита может скачать установщик самостоятельно.

В итоге всех манипуляций, мы получим что-то похожее на "googleearth_4.3.7204.836+0.5.4-1_i386.deb", который можно устанавливать в систему, выкладывать в свой репозитарий (для внутреннего пользования) и т.д.

Смена CPU Affinity - привязки процесса к процессорам в SMP-системе

Давеча этот вопрос был задан, но ответ не сразу нашелся даже в google.
Суть его - как заставить процесс использовать не все процессоры, а только определенные? Для этого в SMP существует понятие "CPU Affinity Mask".
Для этого существует утилита taskset, входящая либо в пакет util-linux, либо schedutil.

taskset 0x00000001 command

заставит команду использовать только 1-й процессор системы

Вместо битовой маски можно использовать и просто список процессоров, а используя ключ -p - менять маску для уже запущенных процессов:

taskset -c 0,3 -p 12345

Как не терять историю команд?

Часто бывает, что мы пользуемся шеллом одновременно из нескольких открытых окон терминала. При этом не менее часто бывает, что удобную и длинную команду из истории шелла из одного терминала случайно затерла история шелла из другого терминала. Избежать этого может помочь добавление следующих строк в .bashrc:

shopt -s histappend
PROMPT_COMMAND='history -a; history -n'

Первая опция заставляет шелл не перезаписывать файл истории, а добавлять записи в него. Вторая команда будет вызывать добавление содержимого истории в файл и перечитывание файла истории сразу при выводе приглашения командной строки, а не после выхода из шелла.



("Кросспост" с Полезные советы по Linux)

X.org 7.3, Debian Sid и клавиатура

После aptitude upgrade неожиданно обнаружил, что в иксах перестали работать старые комбинации клавиш (Ctrl-Alt-F1, например, гг). В поисках проблемы наткнулся на пакет xkb-data-legacy, который заменяет новый xkb-data - это решает проблему.

Но позже adjkerntz с #linux подсказал, в чем проблема - дело в том что вариант winkeys из новой версии xkb-data убрали, поэтому XkbVariant из конфига надо убирать.

Итак, я снова установил xkb-data и стер ",winkeys" из конфига xorg.conf - и полет нормальный!

Excel, сетевые принтеры и тормоза

Как ни странно, жалобу пользователя на "долго открывается Excel" пришлось решать именно с помощью Wireshark. Ибо задержки, примерно похожие на ожидание таймаута ARP =)... как-то связаны обычно с сетью.

А что же делает Excel при запуске? Оно зачем-то лезет за сетевыми принтерами. И если эти принтеры находятся на недоступном сервере, он исключительно противно тормозит при запуске. Вот так все просто. Как лечить без удаления принтеров - пока не знаю.

О туннелях в linux

Те, кто все-таки читал Linux Advanced Routing and Traffic Control HOWTO знают, что с помощью ip tunnel add можно создать ipip, gre или sit туннель. Но вчера случайно возник вопрос:

dpmmsrv:/home/stasikos# ip tun add gre0 local 192.168.20.250
ioctl: No buffer space available

Но:

dpmmsrv:/home/stasikos# ip tun sh
gre0: gre/ip  remote any  local any  ttl inherit  nopmtudisc

Да и вообще странно, что его нельзя удалить:

dpmmsrv:/home/stasikos# ip tun del gre0
ioctl: Operation not permitted

То же самое можно заметить, если вы создали ipip-туннель с именем tunl0, или sit-туннель с именем sit0.

Да, можно гуглить по этой ошибке. Скорее всего ответ вы найдете только в этой статье, если будете искать ответ на вопрос "как удалить tunl0".

Вот, ответ - по крайней мере до 2.6.22 (выше не проверял) - удалять туннели с именами tunl0, gre0, sit0 не удается.

Если почитать документацию к iproute2, можно заметить, что эти туннели называются "base devices". Это специальные устройства, у которых remote и local адреса устанавливаются в "any", и это конечный пункт для туннелированных пакетов, если они не попадают в критерии другого туннеля.
Туннель с другим именем с remote any local any создать нельзя. Нет, система не ругается, но туннель просто не создаст:

dpmmsrv:/home/stasikos# ip tun add gre1   
dpmmsrv:/home/stasikos# ip tun sh gre1
ioctl: No such device

Но если указать хотя-бы один адрес - ради бога, вот он:

dpmmsrv:/home/stasikos# ip tun add gre1 local 192.168.20.250
dpmmsrv:/home/stasikos# ip tun sh gre1
gre1: gre/ip  remote any  local 192.168.20.250  ttl inherit 

Да, и такой туннель легко удаляется:

dpmmsrv:/home/stasikos# ip tun del gre1
dpmmsrv:/home/stasikos# ip tun sh gre1
ioctl: No such device

Полный ответ на этот вопрос есть в исходных кодах модулей ядра, которые и включают поддержку туннелирования. Откроем, например, net/ipv4/ip_gre.c.
В нем есть вот такие вот строки:
/* Fallback tunnel: no source, no destination, no key, no options */
static int ipgre_fb_tunnel_init(struct net_device *dev);
Вот это вот и есть gre0 устройство, которое создается при инициализации модуля:
(в __init)

ipgre_fb_tunnel_dev = alloc_netdev(sizeof(struct ip_tunnel), "gre0",
ipgre_tunnel_setup);

Причем в функциях конфигурирования и удаления туннелей мы заметим особые случаи попыток удаления и перенастройки этого fallback tunnel, которые и вызывают появление ошибки ioctl:Operation is not permitted:

case SIOCDELTUNNEL:
err = -EPERM;
if (!capable(CAP_NET_ADMIN))
goto done;

if (dev == ipgre_fb_tunnel_dev) {
err = -EFAULT;
if (copy_from_user(&p, ifr->ifr_ifru.ifru_data, sizeof(p
)))
goto done;
err = -ENOENT;
if ((t = ipgre_tunnel_locate(&p, 0)) == NULL)
goto done;
err = -EPERM;
if (t == ipgre_fb_tunnel_dev->priv)
goto done;
dev = t->dev;
}
err = unregister_netdevice(dev);
break;


Как раз где-то тут оно и намеренно выдает эту ошибку.

P.S. Ничего страшного в том что туннель останется, нет.

Обзор ресурсов для сисадминов *nix и просто гиков.

Linux
http://linux.org.ru - есть замечательный раздел http://www.linux.org.ru/books и там можно найти LOR FAQ, за который этот ресурс и удостоился помещения сюда. Также можно глянуть http://www.linux.org.ru/view-section.jsp?section=4, где есть еще немножко ссылок.

http://tldp.org - официальный сборник документации по Linux (The Linux Documentation Project), где можно найти HOWTO на многих языках, включая русский.

http://www.unix.org.ua - здесь есть неплохой раздел документации на русском языке на различные тематики.

http://gentoo-wiki.com - сборник документации по Gentoo Linux, есть и русский раздел.

http://citkit.ru/ - много разной информации. Не только по *nix

http://linuxforum.ru/ - русский форум пользователей Linux

http://www.lfwiki.ru/Заглавная_страница - неплохой сборник всяких HOWTO на русском.

http://rusmafia.org/linux/ - сборник советов по Linux, BSD и другим. Дружественный мне проект, ибо участвую с первых дней.

UPD: http://lartc.org - Linux advanced routing and traffic control howto - известный ресурс и дока по возможностям маршрутизации и шейпинга в Linux. (via ).

UPD: http://runix.org - портал с множеством русских блогов по *nix. (via dandr)

Ресурсы по Debian GNU/Linux

http://wiki.debian.org/ - официальный Debian Wiki. Ну, все говорит само за себя.

http://www.debian-administration.org/ - это ресурс (к сожалению, англоязычный), на котором можно найти огромное множество советов по администрированию Debian GNU/Linux.

http://www.uptimebox.ru/ - "Прикладная дебианавтика" - еще один блог сисадмина, работающего с Debian. Пишет свои обзоры, мысли, почитать интересно.

http://beshenov.ru/debaday - "Пакет дня Debian" - задумывался изначально как обзор какого-нибудь одного пакета из репозитария в каждой статье. Иногда попадается ну очень интересный софт. Является переводом другого блога -

http://debaday.debian.net/ - "Debian package of a day"

Юмор
http://ru.thedailywtf.com/ - сборник разных курьезных историй (точнее их переводов).

Порнография для сетевых инженеров

Эротика

BDSM, много боли

via bansheezm

P.S. Мне кажется, я понял, в чем тут разница. Первые тянут сразу жгут из кабелей, вторые - по одному кабелю. Ну и потом вторым лень правильно их уложить и обрезать лишнее...
P.P.S. Ну и специфику надо все-таки учитывать - у нас таки обычно помещения снимают, а не покупают. В результате, построенную на года СКС мало где встретишь. Я уже не говорю про сертифицированные.

О субкультуре в IRC или как не раздражать других )

Итак, 15 правил дурного тона, которые нужно обязательно выполнять, находясь в одной из сетей IRC.

1. Цветные сообщения.
Совершенно необходимо раскашивать сообщения разными цветами. Еще лучше использовать цвета, которые отображаются как "мигающие". Особенно рулит письмо зеленым текстом на зеленом фоне. Такие сообщения сразу выделяются и бросаются в глаза, вызывая множество ответных реплик.

2. Скрипты.
У вас обязательно должны быть установлены разные скрипты. Как минимум один - показывающий, что же играет в вашем плеере. Поверьте, собеседникам очень интересно знать, какая музыка играет у вас в колонках. И еще один - который напишет во все каналы что вы отошли при неактивности клиента. Это очень важная для всех подробность, которую нельзя не сообщить.

3. Выделение ника собеседника.
Совершенно некрасиво и неправильно пользоваться умолчательным способом вставки ника - с запятой или двоеточием вконце, нужно обязательно добавить 4-5 символов слева и справа, снабдив это приправой из цветов. Во-первых это выделит Вас перед остальными, во-вторых, заставит собеседников внимательнее просматривать все каналы, так как скорее всего hilight на такое обращение не сработает - пусть развивают этот навык.

4. Public-away
При уходе надо обязательно менять ник на что-то вроде Вася[away] или Вася|away. Потому что команда /away очень неудобна сама по себе, а все собеседники должны быть в курсе, что вы отошли.

5. Реклама в /quit.
Нельзя не порекламировать свой IRC-клиент или скрипт или даже сайт в quit-сообщении. Кроме того, каждый уважающий себя разработчик клиента обязательно должен оставить ссылку на сайт клиента в умолчательном quit-сообщении, украсив его цветами. Без этого вас не ожидает непонятно откуда взявшийся бан на нескольких каналах. Без этого никуда.

6. Номер в нике
... признак необразованного бота. Совершенно необязательно называться уникальным именем или авторизоваться у сервисов, ведь все и так знают, что вы - это вы.

7. Копи-паст.
Для всех очень важно получить ваш лог с ошибкой/вашу программу/статью прямо в канал, а не с помощью ссылки, а потом читать его. Ведь это так экономит ресурсы сети...

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

9. Повтор сообщений.
Если никто не отвечает на ваше сообщение - это повод повторить его. Еще и еще раз. Его скорее всего просто никто не заметил.

10. Ник со смесью кириллицы и латиницы.
Автокомплит ников - это неправильный подход. Пусть собеседники копируют и вставляют ваш ник руками. Это дань уважения к вам.

11. Новый канал.
Совершенно необязательно читать правила канала и FAQ перед тем как начать что-то писать. Их написали просто для прикола.

12. Кодировка.
В окне сервера никогда не пишут правду. Поэтому подробности настройки кодировки клиента нужно узнавать именно на каком-нибудь канале. И он не должен называться #help - он для этого не предназначен.

13. CAPS LOCK.
Как и в других местах - писать маленькими буквами - дурной тон. Так делают только люди с заниженной самооценкой.

14. /IGNORE
Вместо использования этой команды лучше вылить ушат грязи на надоевшего собеседника. И получить от него в ответ тазик грязи, ответив на него потоком грязи из брандспойта. Ведь это так весело!

15. Autorejoin.
Нужно обязательно включить эту функцию, чтобы не пришлось вручную заходить на канал после кика. Эта команда позволит даже не замечать, что оператор канала чем-то недоволен. Да кто он такой, в конце концов?

Повесть

"Трое в серверной не считая админа"

Случайно, очень случайно наткнулся и прочитал до конца. )

VLSM, CIDR и опять про маски сетей и адресацию.

Итак, мир давно отказался от классовой адресации. Сейчас классы сетей в основном используются только для назначения "умолчательной" классовой маски при настройке интерфейсов хостов. Вот, скажем, введете вы у себя в Windows в настройках tcp/ip адрес 10.0.0.1 - а он автоматически предложит маску 255.0.0.0. В остальном важность понятия класса сети уже утрачена.
Взамен пришли две технологии - VLSM, о которой я уже немножко писал и CIDR. Это две разные технологии, которые замечательно работают вместе и сетевым администраторам могут облегчать жизнь, если использовать их с умом (т.е. там где это реально нужно). Естественно, если у вас в конторе всего один офис из 7 компьютеров, вы можете вообще не изучать ничего из сетевых технологий - вам на этом месте это даже не пригодится. )

Итак, как я уже говорил - VLSM позволяет разделять сети на меньшие по размеру подсети, что позволяет экономить адреса (реальный денежный эквивалент этой экономии получается, если речь идет о покупке подсетей зарегистрированных публичных IP у провайдера)
Забавно, что вместо ручного подсчета есть онлайн и оффлайн-калькуляторы для разбиения адресного пространства. Например, http://www.vlsm-calc.net. ) Но для понимания механизма, полезно все-таки иногда посчитать вручную.
Так как про разбиение диапазонов адресов на подсети я уже писал, пришло время рассказать и об обратной процедуре.
Эта процедура как раз и является частью технологии CIDR и позволяет экономить:
1. На количестве забиваемых руками в таблицу маршрутизации записей.
2. На количестве передаваемых маршрутов в обновлениях протоколов динамической маршрутизации.
3. На числе записей, которые нужно обрабатывать маршрутизатору при поиске маршрутов для каждого пакета.
А называется это "суммирование маршрутов".

CIDR поддерживается любыми устройствами, которые понимают маски сетей, а также протоколами маршрутизации, которые могут переносить маски в своих обновлениях.

CIDR расшифровывается как "Бесклассовая междоменная маршрутизация" (Classless interdomain routing).
CIDR привносит новую и очень краткую форму записей масок - это запись маски в виде количества установленных в "1" бит маски.
Например - 10.0.0.0/8 - означает маску 255.0.0.0 - т.к. 8 бит маски установлены в "1". 192.2.0.0/30 - это 255.255.255.252 - т.к. 30 бит маски установлены в "1", и это просто можно посчитать, переведя маску в двоичный вид.
Для ленивых в Википедии есть табличка, которая поможет перевести такую маску в обычный десятичный вид и наоборот.
Итак, а что же есть суммирование маршрутов?



Ну, возьмем такой пример - допустим у нас есть маршрутизатор, у которого есть "аплинк" в виде другого маршрутизатора, с одной стороны, и две сети - например, 192.168.0.0/24 и 192.168.1.0/24 - с другой. Ну вот прямо как на рисунке. Если перевести оба этих числа в двоичный вид и отсчитать слева совпадающую часть и закрыть ее маской - мы получим суммарную маску для этих двух сетей. :

11000000.10101000.00000000.00000000
11000000.10101000.00000001.00000000
11111111.11111111.11111110.00000000

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

И добавив один этот маршрут - 192.168.0.0/23 - на аплинк, мы вполне нормально обеспечим маршрутизацию пакетов в эти обе сети через наш роутер.

Экономия в числе записей может быть еще чувствительнее, если у нас за маршрутизатором не 2 сети, а много больше.

Перезагрузка Cisco )

Русаковский подсказал достаточно полезную вещь.
Итак, Cisco не сохраняет startup-config сразу. Поэтому если мы что-то настроили не так и не успели сохранить конфигурацию, нас выручит перезагрузка. Но чтобы не делать ее вручную, есть команда reload. Но я вот не знал, что у нее есть еще и параметры )
Итак - reload in [время] - позволяет перезагрузить роутер через указанное количество минут или указанное время. Есть еще reload at - в определенное время. Иными словами, сказав железке перезагрузиться через 5 минут и уже после этого конфигурируя ее, мы автоматически избавляем себя от проблем, связанных с неправильной настройкой.

А если все прошло удачно - нужно просто сказать "reload cancel".

Немножко про access-lists в цисках

Вот, открыл для себя то, что лежит за пределами CCNA - а именно поведение сиськовского пакетного фильтра.
Итак,
1. access-list это список правил
2. access-list работает как любой другой пакетный фильтр - правила применяются по очереди, и если уж подходят к пакету, больше не применяются.
3. В конце любого access-list неявно добавляется правило, которое запрещает все.

Поэтому если хочется прибить только входящий RIP на уровне пакетов, то нужно написать:
access-list 100 deny udp 192.168.4.0 0.0.0.255 any eq rip
access-list 100 permit ip any any

Отредактировать строку списка никак нельзя. Можно только удалить список полностью:
no access-list 100

И потом добавить его заново.
Правила добавляются в порядке ввода. )

access-list необходимо назначать на интерфейс или в других местах, где он поддерживается:
(config) int fa1/0
(config-if) ip access-group 100 in

Нужно быть очень осторожным, добавляя правила удаленно, особенно на интерфейс, чреез который подключаешься через vty - есть опасность набокопорить и потом бежать к циске с ноутбуком и консольным кабелем или тупо просить ее кого-то перезагрузить. )

Сиськочасы

Подарок нашему инструктору... В общем, он одарил нас самой большой аудиторией и в ней будут вот такие вот часы. )
Картинко под катом

Ааа! Моя корзина не очищается и я почему-то не могу удалить свои документы!

Все-таки есть одна неприятность, которая приходит с удалением winbindd-idmap.tld - слетают привязки id UNIX-юзеров к юзерам домена. В результате очень неприятно меняются права доступа юзерам к каталогам, посему... В общем, теперь я резервнокопирую этот файлик и вам рекомендую. Мало ли что. Вдруг пьяный техник перепутает шнур питания сервера с чем-то еще. )

Аааа! Мы не можем открыть папку с документами!

Как-то неаккуратно вырубился файловый серевер с samba и winbind и у некоторых юзеров домена отвалился доступ к нему. )

[2008/03/05 13:23:24, 1] nsswitch/winbindd_user.c:winbindd_getpwent(729)
  could not lookup domain user irina
[2008/03/05 13:23:24, 0] tdb/tdbutil.c:tdb_log(783)
  tdb(/var/lib/samba/winbindd_idmap.tdb): rec_read bad magic 0x42424242 at offset=21508
[2008/03/05 13:23:24, 0] tdb/tdbutil.c:tdb_log(783)
  tdb(/var/lib/samba/winbindd_idmap.tdb): rec_free_read bad magic 0x42424242 at offset=21760
[2008/03/05 13:23:24, 1] nsswitch/winbindd_user.c:winbindd_fill_pwent(85)
  error getting user id for sid S-1-5-21-578002964-3223751266-3916644461-4113
[2008/03/05 13:23:24, 1] nsswitch/winbindd_user.c:winbindd_getpwent(729)
  could not lookup domain user elena

Лечится, в общем-то, элементарно - rm /var/lib/samba/winbindd_idmap.tdb и /etc/init.d/winbind restart. )

О настройке RIPv1 в Windows 2003 Server

Я не знаю, как Microsoft позиционирует свою систему на маршрутизаторы и почему, потому что, имхо, это не лучший выбор по соотношению цены и возможностей. Но Windows Server поддерживает динамическую маршрутизацию и RIP в том числе. Как обычно, есть два варианта настройки - через rrasmgmt.msc и netsh

Рассмотрим первый вариант.

Пуск -> Выполнить -> rrasmgmt.msc

Получаем консоль управления маршрутизацией и удаленным доступом. Удалим оттуда маршруты, которые мы добавили ранее. Далее кликнем правой кнопкой своего грызуна на "General" и выберем пункт "New Routing Protocol".



В появившемся окне выбираем "RIPv2 for Internet Protocol".
У нас в дереве под "IP Routing" появится соответсвующая ветка, тыкая опять же на которую правой кнопкой, можно добавлять интерфейсы, которые будут участвовать в работе протокола. Добавим туда все интерфейсы, кроме Control - RIP на нем работать не должен.



При добавлении интерфейса необходимо сразу же настроить его. Это можно сделать и позже, но проще - прямо сейчас.



Итак, я задаю для интерфейса использование протокола RIPv1 для приема и отправки обновлений соседям, оставляю периодический режим для рассылки обновлений и не включаю аутентификацию. RIPv1 ее не поддерживает.
Раз уж мы в этом окне, опишу и остальные вкладки:



На вкладке "Security" можно настроить фильтры для обновлений - какие принимать и какие рассылать (или не принимать и не рассылать).



На вкладке "Neighbors" можно настроить отношения с соседями. Либо вы общаетесь с ними стандартным методом, либо прописываете дополнительных соседей, которым обновления будут посылаться направленно, либо - всем соседям будете посылать обновления направленно.



На вкладке "Advanced" включаются и отключаются дополнительные функции RIP - расщепление горизонта, poisoned reverse и триггерные обновления. Кроме того, можно поменять умолчательные значения таймеров и задать дополнительные условия для рассылки маршрутов на хосты или сети, а также маршрут по-умолчанию. Здесь лучше оставить все как есть. )



Ну и после активации RIP на интерфейсах и получения первых маршрутных обновлений от соседей, в таблице маршрутизации можно заметить новые маршруты, помеченные, как полученные от протокола RIP.

Как я уже и говорил, аналогичные действия можно выполнить с помощью netsh. Только этот интерфейс не назовешь особенно удобным.
Итак, если теперь снова удалить RIP из протоколов маршрутизации и пойти в netsh...
Для начала установим RIP:

C:\Documents and Settings\Administrator>netsh
netsh>routing ip rip
netsh routing ip rip>install
Ok.

Затем, то же самое что и в консоли - добавим интерфейсы с настройками:

netsh routing ip rip>add int "Stub3" announce=rip1 accept=rip1
Ok.

netsh routing ip rip>a int "n253" ann=rip1 acc=rip1
Ok.

netsh routing ip rip>a int "n254" ann=rip1 acc=rip1
Ok.

netsh routing ip rip>

Ну и напоследок - проверим таблицу маршрутизации на предмет появляющихся там маршрутов от соседей:

netsh>routing ip sh rtmr

            Prefix  Protocol    Prf  Met  Gateway          Vw  Interface
------------------  ----------  ---  ---  ---------------  --  ----------------
        10.0.0.0/8  Local         1   10  10.0.0.7         UM  Control
       10.0.0.7/32  Local         1   10  127.0.0.1        U   Loopback
 10.255.255.255/32  Local         1   10  10.0.0.7         UM  Control
       127.0.0.0/8  Local         1    1  127.0.0.1        U   Loopback
      127.0.0.1/32  Local         1    1  127.0.0.1        U   Loopback
    192.168.3.0/24  Local         1   10  192.168.3.1      UM  Stub3
    192.168.3.1/32  Local         1   10  127.0.0.1        U   Loopback
  192.168.3.255/32  Local         1   10  192.168.3.1      UM  Stub3
    192.168.4.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.250.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.251.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.252.0/24  RIP         120    2  192.168.253.1    UM  n253
  192.168.253.0/24  Local         1   10  192.168.253.2    UM  n253
  192.168.253.2/32  Local         1   10  127.0.0.1        U   Loopback
192.168.253.255/32  Local         1   10  192.168.253.2    UM  n253
  192.168.254.0/24  Local         1   10  192.168.254.2    UM  n254
  192.168.254.2/32  Local         1   10  127.0.0.1        U   Loopback
192.168.254.255/32  Local         1   10  192.168.254.2    UM  n254
       224.0.0.0/4  Local         1   10  10.0.0.7         UM  Control
       224.0.0.0/4  Local         1   10  192.168.3.1      UM  Stub3
       224.0.0.0/4  Local         1   10  192.168.253.2    UM  n253
       224.0.0.0/4  Local         1   10  192.168.254.2    UM  n254
255.255.255.255/32  Local         1    1  10.0.0.7         UM  Control
255.255.255.255/32  Local         1    1  192.168.3.1      UM  Stub3
255.255.255.255/32  Local         1    1  192.168.253.2    UM  n253

Вот, собственно, и вся настройка. )

Как включить и настроить Routed в BSD-системах

Тема эта - больше классика, чем практически полезная, потому что routed морально устарел. Но мне очень хотелось попробовать. )

Итак, чтобы включить routed в BSD-системе, необходимо в случае FreeBSD добавить вот такие строки в /etc/rc.conf:

router_flags=""
router="/sbin/routed"
router_enable="YES"

Либо, в случае OpenBSD - достаточно просто исправить "routed_flags="NO"" на что-то другое, например просто убрать "NO" в том же /etc/rc.conf:

router_flags=""

Можно, конечно, в соответстии с man routed, задать все опции в этих самых кавычках, но так как нам нужен RIP-демон, мы оставим конфигурацию по-умолчанию без ключей и будем пользоваться /etc/gateways для для его настройки. Routed сам определит, что он запущен на маршрутизаторе и начнет распространять маршруты. (Условия для этого - gateway="yes" и наличие более одного сетевого интерфейса).
Кроме RIP этот демон поддерживает и другие методы настройки маршрутизации, например, протокол ICMP, а точнее - сообщения, которые отвечают за анонс/поиск/объявление маршрутизатора. Но так как эти функции пока выходят за пределы рассказа про RIP, рассматривать их я не буду. Да и они, опять же - мало применимы практически и больше относятся к старой доброй классике...
Итак, судя по топологии из предыдущих постов, у нас есть по крайней мере один интерфейс, на котором мы RIP использовать не должны.
Поэтому наш /etc/gateways у нас будет выглядеть вот так:

if=lnc4 no_rip passive
no_rdisc

Он в первую очередь отключает рассылку обновлений через интерфейс lnc4, во вторых - отключает ICMP-функции по работе с маршрутами.

Но на OpenBSD такой метод запрета рассылки анонсов почему-то не прокатил. Поэтому в hostname.pcn3 к настойкам интерфейса я просто добавил метрику 16, что сделало маршрут в сеть на этом интерфейсе недоступным для RIP.:

# cat /etc/hostname.pcn3
inet 10.0.0.5 255.0.0.0 NONE description "Control Interface" metric 16

Да, и надо не забыть запустить routed:

# routed

Для отладки полезно использовать ключи -d и -t:

# routed -d -t 
-- 08:25:51 --
Tracing actions started
Add interface lo0                 -->/32             <loopback> <passive> 
RCVBUF=61440
Add interface pcn0 127.0.0.1      -->/24              
turn on RIP
Add interface pcn1 192.168.1.0    -->/24              
Add interface pcn2 192.168.249.0  -->/24              
Add interface pcn3 192.168.255.0  -->/8              metric=16 <passive> 
start suppying routes
Add    127.0.0.1       -->10.0.0.0         metric=16 <if> pcn3 08:25:51
Add    192.168.1.1     -->192.168.255.0    metric=0  <if> pcn2 08:25:51
Add    192.168.249.1   -->192.168.249.0    metric=0  <if> pcn1 08:25:51
Add    10.0.0.0        -->192.168.1.0      metric=0  <if> pcn0 08:25:51
Add    10.0.0.5/32     -->127.0.0.1        metric=0  <if> lo0 08:25:51

Еще один метод отладки - это использование tcpdump:

# tcpdump -s 512 -i pcn1 -n udp port 520
tcpdump: listening on pcn1, link-type EN10MB
08:29:45.192544 192.168.249.2.520 > 192.168.249.255.520:  RIPv1-resp [items 9]:
{192.168.2.0}(3) {192.168.3.0}(4) {192.168.4.0}(2) {192.168.6.0}(1) 
{192.168.250.0}(1) {192.168.251.0}(2) {192.168.252.0}(2) {192.168.253.0}(2) 
{192.168.254.0}(3) (DF)

Все это позволяет увидеть и то, что рассылает routed, и то, что он получает от соседей. В tcpdump мы видим как раз один из пакетов, которые выслала Quagga на linux-роутере, с маршрутами в известные ей сети.

Иными словами, настройка routed практически тривиальна и не сулит ничего сложного. Кроме RIPv1 он поддерживает и RIPv2. Кроме того, в нем отстутвуют настройки поведения протокола. И почему-то он ведет себя иногда довольно-таки странно. В общем, я так и не понял его местами. Например, в openbsd он почему-то не хочет делать ращепление горизонта, хотя в мануале написано - что он просто не умеет не делать этого.

Настройка RIP в Cisco IOS и Quagga.

Так как в Debian просто нет routed, я использую другой демон динамической маршрутизации - Quagga. Это форк другого демона - Zebra. Основной идеей в нем проглядывается попытка во всем быть похожей на Cisco IOS, поэтому настраиваются они в плане RIP одинаково. Ну почти. )


Итак, чтобы включить RIPv1 в Cisco IOS, достаточно такой последовательности команд:

router rip
 network 192.168.251.0
 network 192.168.252.0
 network 192.168.4.0
 network 192.168.253.0
 network 192.168.250.0

Мы просто включаем rip для перечисленного нами списка сетей. Характерная особенность конфигурации RIP - что любой введенный номер сети автоматически обрезается до классового номера сети.
Сама команда network включает указанную сеть в обновления RIP и одновременно активирует рассылку и прием обновлений RIP на интерфейсах, адреса которых попали в эти сети.


Я пока не удаляю вообще ничего из статических маршрутов, потому что сеть просто перестанет нормально работать, пока все маршрутизаторы не станут понимать RIP.


Чтобы проверить конфигурацию протоколов динамической маршрутизации в IOS, достаточно команды "show ip protocols"

c3745-center#sh ip proto
Routing Protocol is "rip"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Sending updates every 30 seconds, next due in 24 seconds
  Invalid after 180 seconds, hold down 180, flushed after 240
  Redistributing: rip
  Default version control: send version 1, receive any version
    Interface             Send  Recv  Triggered RIP  Key-chain
    FastEthernet0/0       1     1 2                                  
    FastEthernet0/1       1     1 2                                  
    FastEthernet1/0       1     1 2                                  
    FastEthernet2/0       1     1 2                                  
    FastEthernet3/0       1     1 2                                  
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    192.168.4.0
    192.168.250.0
    192.168.251.0
    192.168.252.0
    192.168.253.0
  Routing Information Sources:
    Gateway         Distance      Last Update

Вывод перечислит нам списки фильтров рассылки/приема обновлений для сетей, установки таймеров RIP, типы маршрутов, которые распространяются RIP, какие версии обновлений рассылаются и принимаются интерфейсами и какими. Включена ли суммаризация - об этом подробнее в RIPv2, а также список сетей, для которыx RIP включен. Кроме того, мы могли увидеть список соседей, от которых мы получали обновления - но пока он пуст. )


Теперь установим на linux-роуетере демон Quagga и настроим его:

stasikos@linux-router:~$ sudo aptitude install quagga 

после установки необходимо активировать zebra и ripd в /etc/quagga/daemons:

zebra=yes
ripd=yes

И создадим пустой конфиг для zebra и ripd:

touch /etc/quagga/zebra.conf
touch /etc/quagga/ripd.conf

Теперь рестартуем quagga:

root@linux-router:/etc/quagga# /etc/init.d/quagga restart

После этого, можно подсоединиться к "консоли" Quagga с помощью vtysh:

root@linux-router:/etc/quagga# vtysh

Hello, this is Quagga (version 0.99.5).
Copyright 1996-2005 Kunihiro Ishiguro, et al.

linux-router# 

Не пугаемся. Мы оказались в режиме, который в IOS называется "Privelegied EXEC Mode". Теперь мы можем перейти в режим глобальной конфигурации маршрутизатора и настроить себе rip )

linux-router# conf t
linux-router(config)# router rip
linux-router(config-router)# network 192.168.6.0/24
linux-router(config-router)# network 192.168.249.0/24
linux-router(config-router)# network 192.168.250.0/24

Уже заметна разница между Quagga и IOS - во-первых, Quagga требует ввода маски сети. Во-вторых, она поддерживает указание маски через ее длину. )


Аналог show ip protocols rip в Quagga - это show ip rip status:

Routing Protocol is "rip"
  Sending updates every 30 seconds with +/-50%, next due in -1203234300 seconds
  Timeout after 180 seconds, garbage collect after 120 seconds
  Outgoing update filter list for all interface is not set
  Incoming update filter list for all interface is not set
  Default redistribution metric is 1
  Redistributing:
  Default version control: send version 2, receive any version 
    Interface        Send  Recv   Key-chain
    eth0             2     1 2    
    eth1             2     1 2    
    eth2             2     1 2    
  Routing for Networks:
    192.168.6.0/24
    192.168.249.0/24
    192.168.250.0/24
  Routing Information Sources:
    Gateway          BadPackets BadRoutes  Distance Last Update
    192.168.250.2            0         0       120   00:00:03
  Distance: (default is 120)
 

Кстати, внизу мы видим соседнюю циску. Это не может не радовать. Но она нас не видит. Очевидно, Quagga по-умолчанию рассылает обновления версии 2, что из вышепоказанного вывода мы и видим. ) Исправим это:

linux-router(config)# router rip
linux-router(config-router)# version 1

Вот теперь с3745-center нас увидит. Проверим, какие маршруты мы получили от него через RIP:

linux-router# sh ip ro rip

Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route

R   192.168.4.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.251.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.252.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46
R   192.168.253.0/24 [120/2] via 192.168.250.2, eth0, 00:05:46

Можно сказать "все работает" и перейти к конфигурации какого-нибудь еще маршрутизатора из оставшихся.

10 советов, на случай если вам в голову пришла идея пересобрать ядро linux

Я вообще никогда не рекомендовал собирать ядра самостоятельно, если это явно не требуется. Сам всегда пользуюсь дистрибутивным ядром и если когда его и собирал - так это ради накладывания патчей. Не понимаю, почему каждый новичок норовит сделать это, не зная совершенно, чем это грозит?
Поэтому у меня сложилось несколько мыслей относительно сборки ядра:
1. Если вы не знаете точно, зачем вы хотите собрать собственное ядро - не собирайте его.
2. Если ваше текущее ядро работает и поддерживает все необходимое оборудование и технологии, и не имеет критических уязвимостей - не собирайте свое ядро и не обновляйте старое.
3. Если вы не в состоянии решить проблемы с новой версией ядра (например, поправить часть исходного кода модуля от сторонних производителей для сборки на новом ядре) самостоятельно - не обновляйте ядро.
4. Если нужное ядро уже есть в виде пакета для вашего дистрибутива (особенно в репозитариях дистрибутива) - не собирайте свое ядро.
5. Если вы все-таки решились - прочитайте не только Kernel HOWTO, но руководство для сборки ядра именно для своего дистрибутива. Поищите в поисковике информацию о проблемах со сторонними модулями и программным обеспечением, которое использует свои собственные модули в ядре для работы.
6. Не трогайте конфиг ядра больше, чем нужно. Особенно, если не знаете, что делаете.
7. Если часть модулей для оборудования вы добавили как модули - не забудьте собрать и initrd для ядра перед тем, как делать reboot.
8. Не забудьте оставить и старое рабочее ядро в системе и в загрузчике, чтобы можно было откатиться, если что-то пойдет не так.
9. Если что-то не получилось - не паникуйте - поищите в google по полученному сообщению об ошибке - скорее всего ответ вы найдете сразу же (обычно обжигаются еще тысячи пользователей).
10. Простая пересборка ядра скорее всего не даст прироста производительности и не сильно освободит оперативную память. А установка недистрибутивных ядер вынудит вас собирать проприетарные драйверы самостоятельно и хранить все дерево исходных текстов ядра на винчестере. Подумайте об этом.

Протокол динамической маршрутизации RIP версии 1

Нет, RIPv1, конечно, R.I.P в каком-то смысле, но это фактически первый и самый простой протокол динамической маршрутизации, который был стандартизован, открыт и реализован практически в любой операционной системе.

Если мы наберем в поисковике фразу "RFC RIP", мы тут же найдем RFC 1058, в котором полностью описана история, работа и реализация такого протокола.

Этот документ описывает работу RIP в routed, стандартном юниксовом демоне динамической маршрутизации - самой первой практической реализации этого протокола. )

RIP является протоколом внутренней маршрутизации, основанном на дистанционно-векторном протоколе Беллмана-Форда.

Протокол ограничен максимальным расстоянием в 15 хопов (маршрутизаторов) между конечными сетями и не распространяет в своих обновлениях маски сети, то есть не поддерживает такие технологии как VLSM и CIDR. Кроме того, его использование может приводить к "маршрутным петлям", эффект от которых уменьшается только наличием поля TTL в заголовках IP-пакетов. Кроме того, мерой стоимости маршрута (и основанием для выбора между несколькими маршрутами в одну сеть) является только число хопов. RIP не может учитывать ни загрузку каналов, ни их пропускную способность.
В своей работе RIP использует udp-дейтаграммы, рассылаемые широковещательно с порта 520 на порт 520. Дейтаграмма имеет очень простой формат, в котором, к тому же, заложены возможности развития протокола. Фиксированная часть заголовка содержит только поле версии и тип дейтаграммы - запрос или ответ. Остальную часть занимают записи маршрутов, которые состоят из типа протокола, чья информация переносится (для IP это 2), адреса сети назначения, пары забитых нулями зарезервированных полей и поля метрики маршрута. Максимальный размер сообщения составляет 512 байт, что означает, что переносить в нем можно только 25 маршрутных записей (но это не значит, что больше 25 маршрутов вообще переносить нельзя - вполне себе можно делать это в отдельных сообщениях).

Как работает маршрутизатор с протоколом RIP.
Сразу после включения маршрутизатор рассылает широковещательно пакеты, содержащие его таблицу маршрутизации, в которой будут находиться только маршруты в подключенные сети. При этом для каждой записи он будет указывать метрику 1. То же самое делают и его соседи. Кроме того, он прослушивает сеть на предмет появления таких же сообщений от других маршрутизаторов и анализирует их.
Если в сообщении встречается маршрут в неизвестную до этого сеть, маршрутизатор добавляет ее в собственную таблицу маршрутизации.
Если в сообщении встречается маршрут в уже известную сеть, и его метрика меньше метрики уже имеющегося маршрута - он заменяет запись в своей таблице на новую. Если метрика больше - считается, что этот маршрут хуже и добавлять его не стоит. ) Поэтому он просто проигнорирует такую запись.
После того, как пройдет 30 секунд после первого обновления, маршрутизаторы повторяют эту процедуру снова, рассылая свои таблицы маршрутизации широковещательно. При этом стоит заметить, что полученные от соседей маршруты в подключенные к ним сети они будут рассылать уже с метрикой, большей на единицу, то есть равной двум. Это будет продолжаться, пока все маршрутизаторы в сети не будут иметь маршруты во все известные сети.
Время, которое будет затрачено на полное построение всех таблиц маршрутизации на всех маршрутизаторах в сети называется временем сходимости сети (convergence), и, с учетом 30-секундного интервала обмена маршрутами, для сети из трех маршрутизаторов, это время будет равно максимум 30 секундам, в случае если все маршрутизаторы просто включили одновременно. Для сети, в которой между двумя максимально удаленными сетями находится 16 маршрутизаторов (предел для RIP) это время составит уже 7 минут. Это также худшее время сходимости при добавлении новой сети.

На самом деле таймер обновления может и не быть равен ровно 30 секундам, его даже рекомендуют увеличивать на небольшое случайное число при каждом старте таймера, чтобы в сетях типа Ethernet рассылка обновлений не вызывала коллизий.

Нам необходимо не только отслеживать появление новых сетей, но и исчезновение старых. Механизм для этого есть - для каждого маршрута, полученного через протокол RIP, в маршрутизаторе создается отдельный таймер, по истечении которого маршрут удаляется. Это время по-умолчанию установлено в 180 секунд, чтобы не считать маршруты недоступными в случае, если какие-то 1-4 пакета с обновлениями просто потеряются в сети.
Но стоит только промоделировать ситуацию с "отвалившейся" сетью на бумаге или на реальном железе, мы увидим, что в классическом варианте RIP она разрешается очень плохо. )
Дело в том, что маршрутизатор, сеть на котором была удалена из таблицы маршрутизации, тут же получит ее от соседа, хотя и с большей метрикой. И завернет весь траффик в нее - на соседа, и тут же образуется маршрутная петля. В течение 180 секунд, пока его сосед будет считать этот маршрут еще действительным, он будет пересылать пакеты в нее нашему роутеру, а он будет отсылать их обратно соседу - ведь маршрут в эту сеть он получил именно от него! ).
Но дальше ситуация становится еще более печальной. Как только маршрут удалится из таблицы второго маршрутизатора, он снова появится там с метрикой, выросшей на единицу - так как получит его сразу от соседей, образовав новые маршрутные петли. Ситуация будет развиваться в худшую сторону, образуя петли во всей сети, пока, наконец, метрика маршрута не станет равна 16. Это пометит маршрут как недоступный, и приведет к удалению его из таблицы маршрутизации (конечно, только если этот маршрут добавлен RIP). Таким образом, сеть все-таки сойдется, в самом плохом случае - через 48 минут. Это уже не такое приемлемое время, как 7 минут на "холодный старт" сети, с учетом того что все каналы связи будут заняты пересылкой пакетов в маршрутных петлях, вместо передачи полезных данных. Как раз тот случай, когда в математике все хорошо (сеть сошлась), но на практике неприемлемо (слишком долго сходилась).

С целью разрешить проблему сходимости сети для случаев, когда ранее доступные сети становятся недоступными, в RIP было добавлено два механизма.
1. Расщепление горизонта. Маршрутизатор анализирует маршруты перед отправкой и не рассылает через свои интерфейсы те маршруты, которые он получил через них же. Иными словами, если сеть отваливается, маршрутизатор не получит от соседа обновление через 180 секунд о маршруте, который он сам же ему отослал и петля образовываться не будет.
2. Отравление маршрутов или poisoned reverse. ) Маршрутизатор использует технику расщепления горизонта, но вместо того чтобы совсем не рассылать маршруты, полученные от соседей, им же - рассылает их с метрикой 16, сразу сообщая им о недоступности сети.

На самом деле в RIP может быть и больше таймеров - но особенности реализации все-таки присутствуют, как и умолчательные значения. Например, Cisco IOS после падения маршрута в первые 180 секунд считает его рабочим, далее - деактивирует, но все еще держит в таблице - причем, как "possibly down", с метрикой 16, пока не истечет еще один таймер - таймер захоронения. Опять же, чтобы не дай боже кто-нибудь не прислал его снова и не создал новую петлю )

Так что, как видно, расещпление горизонта - настолько нужная в RIP методика, что в большинстве современных RIP-маршрутизаторов она включена по-умолчанию. )

Ну и так как практически в любой ОС есть поддержка RIP - встроенная или нет - есть, что показывать в плане настроек.

Лытдыбр натуральный

Так что если вы ходите сюда за записями с тегом "computer-academy-step", можете просто не читать то что под катом...

А началось все с фразы "если мы будем жить вместе"...

Я никогда не задумывался об этом. Но, может кому-то покажется бредом сумасшедшего, а мне так не кажется. Все это, имхо, грань между детством и чем-то более ответственным и осмысленным. Действительно, где-то там, за этой гранью - отношение к противоположному полу, как к сиськам, попе, поцелуйчикам, сексу, в конце концов. Но если только задуматься, насколько все на самом деле глубже, и что на самом деле значит это "быть вместе" - я сначала просто ужаснулся. Во-первых, это значит, что привычный уклад жизни может совершенно меняться, особенно для такого гика и одиночки как я - дома появится человек, который будет требовать к себе море внимания. О ней надо будет заботиться, ее нужно будет даже обеспечивать, кроме того - заботиться и о ее родителях тоже, не так ли? Нет, можно сразу отказаться от этих обязанностей, но это уже будет не "вместе", это будет только "вместе в постели". Да, придется терпеть выходки. Да, у нее будут ПМС и все последствия тоже будут отражаться на тебе - изволь заботиться о ней в эти дни. Да, еще тебе придется понимать, что с работы она может прийти усталой и грустной и дело не в тебе, и не стоит заострять на этом внимание, и скандалить по поводу того, что она сегодня не хочет тебя ублажать и вообще кажется неласковой. Угу, еще у нее есть свои тараканы и бзики - и либо ты к ним привыкнешь, либо перевоспитаешь ее, либо ты уйдешь. Или она уйдет. Да, от нее, конечно, тоже много зависит. Есть ли у нее терпение? А у тебя?
Решения принимать только для себя тоже уже не получится. Нет, может это я так демократичен сам по себе, но мне кажется, что учитывать и ее интересы придется тоже. Да, не стоит забывать и про финансовую сторону дела. Все кажется таким простым, но тоже придется делать выбор не в пользу себя. Забудь про новые гаджеты. )
А доверие?
Нет, только взвесив все "за" и "против", можно вообще думать о каком-то сверхромантичном "вместе до гроба". Все что лезет в голову до этого момента, не имеет даже права на жизнь, только самообман и бред - потому что на самом деле все намного серьезнее, если твоя цель - это не только секс и приятное времяпровождение. И выбор этот непростой.

USBMount

Сегодня понял, что совершенно надоевшим для меня стал процесс "фтыкнул сменный носитель, так пропиши...". В общем, задался мыслью, как без навороченного DE в своем fluxbox получить автоматическое монтирование любых съемных накопителей, втыкаемых в USB.

На #linux@Rusnet посоветовали попробовать usbmount.

С дефолтными настройками она вряд-ли кому подойдет, поэтому приведу то, что нужно поменять для получения счастливой улыбки на лице.

И сразу же испорчу настроение испытывающим радость. )


В общем, после установки пакета, в /etc/usbmount/usbmount.conf нужно немного поменять строчки в вот такой вид:

# vfat по-дефолту отключен - читайте, почему, в комментах выше строки
FILESYSTEMS="ext2 ext3 vfat"
# async тоже по-дефолту отключен, причины там же
MOUNTOPTIONS="async,noexec,nodev,noatime"
# а вот эта строка просто жизненно нужна для вменяемого поведения с vfat. 
FS_MOUNTOPTIONS="-fstype=vfat,uid=stasikos,gid=floppy"

В общем, неплохое решение для героев-одиночек без среды рабочего стола, но с каким-нибудь минималистичным оконным менеджером типа fluxbox.

Недостатки -

1. При юзании vfat нужно не забывать руками делать команду sync перед вытыканием флешки (или, как некоторые джедаи, совать sync в crontab). Потому что монтирование с записью в sync приводит к редкостным тормозам в записи на накопитель (я так понял, что проблема в vfat - плохо работает в таком режиме).

2. При юзании vfat вряд-ли удастся настроить приемлемую работу с несколькими пользователями за компьютером - в силу того что монтирует накопитель сам usbmount, делает он это с правами root, и не использует записи в fstab, так что установить uid для владельца флешки можно только один, через тот же usbmount.conf. При попытке вывернуться с помощью fmask/dmask вы будете получать "Can't change permissions: operation is not permitted" при записи каждого файла на флешку.

Wireshark - анализатор пакетов.

Утилитка, может быть, "крекерская", но ее использование упрощает понимание процессов, которые происходят в сети и может быть полезно при изучении сетевых протоколов и даже при простом обыденном поиске проблем.

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


Скачать ее, под *nix или под Windows, можно с сайта wireshark.org. Раньше она называлась Ethereal. ) Кроме того, она включена в большинство крупных дистрибутивов Linux и *BSD.


Для начала работы с Wireshark требуется хотя-бы захватить какие-либо пакеты. Удобнее всего это делать через "Capture options", расположенное на главной панели и
нструментов или в меню Capture.

В опциях нужно задать интерфейс компьютера, на котором нужно отлавливать пакеты. Также можно задать, делать ли это в promisc режиме (т.е. слушать весь траффик) или нет (получать только пакеты для этой машины). Тут же для удобства можно выбрать опции показа захватываемых пакетов - обновлять ли список в реальном времени и прокручивать ли список автоматически. Удобно обычно поставить сразу все галки.)



После этого wireshark начинает, как правило, что-то захватывать...



... и показывать список захваченных пакетов, из которых можно выбирать пакет для более поднобного анализа. В среднем окне показывается декодированный пакет (т.е. wireshark сам раскладывает пакет по полям для известных протоколов). В нижнемокне показывается пакет или кадр в виде "как есть" (raw). Причем, выбранная в среднем окне часть будет подсвечиваться - так что даже без соответствующего RFC можно изучить формат заголовка интересного тебе протокола и т.д. )

Кроме того, в wireshark есть несколько удобных и полезных функций. Например, Analyse -> Expert Info Composite покажет список основных событий, которые произошли во время захвата - открытие новых сессий, не совсем хорошее поведение протоколов (повторные квитанции в TCP, повторные передачи сегментов и т.д.).



Там же - Follow (TCP|UDP|SSL) Stream - позволяет собрать сессию передачи воедино и посмотреть ее содержимое в целом - вплоть до восстановления переданной в течение сессии HTML-страницы. )



Statistics->Summary позволяет просмотреть некоторую статистику в целом по сессии захвата - в том числе, среднее количество пакетов в секунду и объем передава
емых данных.



Statistic -> Protocol Hierarhy - статистику по используемым протоколам, в том числе - в процентном соотношении.



Statistics -> Conversations показывает информацию об участниках связи, кто кому сколько передавал пакетов, данных и в какую сторону. )



IO Graphs в том же меню позволяет отстроить почти произвольный статистический график по захваченным данным. (допустим, график с двумя линиями - широковещательный и юникаст траффик, для того чтобы делать какие-то выводы... )



Ну и для совсем уж ленивых людей, wireshark может автоматически генерировать правила для блокировки или разрешения траффика, похожего на выбранный пакет. Analyse - Firewall ACL Rules. При этом можно выбрать тип файрвола (Cisco acl, Netfilter, windows firewall и т.д.)



Кроме захвата пакетов непосредственно Wireshark, можно использовать tcpdump с опцией -w:

tcpdump -i ppp0 -w file.pcap

И затем открывать полученный файл в Wireshark для просмотра.

В общем, утилита удобная и должна быть Must Have у любого администратора. ) Единственное, чего в ней может не хватать - это генератора пакетов, но для этого есть другие, более подходящие средства.

О заголовке IP-пакета и назначении его полей.

Немножко перевода из RFC, а также про TTL и фрагментацию.


(RFC 791)

Заголовок пакета может занимать от 20 до 60 байт.

Version	IHL	Type Of Service	Total Lenght
Identification			Flags	Fragment Offset
Time To Live		Protocol	Header CheckSum
Source Address
Destination Address
Options			Padding

Поле Version (4 бита) - указывает на версию протокола IP, которой соответствует пакет. В настоящее время пакеты с таким заголовком содержат только значение "4".

IHL (4 бита) - Длина заголовка пакета - используется для определения границы, на которой заканчивается заголовок IP-пакета и начинаются данные, которые он переносит. Длина указывается в 32-битных словах.

Type Of Service (8 бит) - указывает на абстрактные параметры желаемого качества обслуживания для пакета. Может быть использовано маршрутизаторами и другими устройствами 3-го уровня для определения наиболее подходящего по параметрам маршрута. Основной выбор состоит между низкой задержкой, высокой надежностью или высокой пропускной способностью. При этом биты 0-2 указывают на приоритет пакета, бит 3 - на уменьшение задержки при доставке, бит 4 - на выбор маршрута с высокой надежностью доставки, бит 5 - выбор маршрута с наибольшей пропускной способностью, биты 6-7 - зарезервированы. На самом деле используется только внутри одной сети и может не сыграть вообще никакой роли при передаче пакета через Internet, так как политики обработки пакетов устанавливаются конкретной организацией, управляющей автономной системой.

Total Lenght (16 бит) - общая длина IP-пакета в байтах.

ID - очень важное поле, предназначенное для правильной сборки фрагментированных пакетов.

Дело в том, что в различных протколах канального уровня максимальный размер кадра может отличаться, а это значит, что максимальный размер IP-пакета ограничен этим самым размером, который называется MTU - Maximum Transfer Unit. Но так как при прохождении очередного маршрутизатора пакет может попасть в сеть с меньшим MTU, чем в той, в которой он был создан, он может быть разбит на меньшие части. При этом в заголовке каждой части будет указано одинаковое значение ID, которое говорит о том, к какому пакету эти части относились.

Flags - 3 бита - Поле флагов. Первый бит зарезервирован и всегда должен быть установлен в 0. Второй бит, при установке в значение "1" указывает на то, что фрагментация пакета запрещена (и если она понадобится, пакет не будет доставлен). Третий бит указывает на наличие или отсутствие следующего фрагмента этого пакета. Иными словами, установлен в 0 может быть либо, если пакет не фрагментирован, или если это - последний фрагмент пакета.

Fragment Offser - значение смещения начала фрагмента внутри оригинального пакета, единица в этом поле одначает 64 бита. Смещение первого фрагмента всегда равно 0.

Time To Live - используется для решения проблемы "count to infinity" и помогает маршрутизаторам "пристрелить" пакет, который слишком долго находится в сети. Уменьшается на единицу каждым маршрутизатором при пересылке пакета. Таким образом, даже если в сети есть маршрутная петля, пакет не будет пересылаться от одного маршрутизатора к другому и обратно вечно, а будет уничтожен, как только поле TTL примет значение 0.

Protocol - указывает номер протокола, PDU которого вложен внутрь этого IP-пакета.

Header Checksum - контрольная сумма заголовка пакета. Пересчитывается каждый раз при смене заголовка - например, если он проходит через очередной маршрутизатор.

Source Address (4 байта) - IP-адрес источника, отославшего пакет.

Destination Address (4 байта) - IP-адрес назначения, куда был послан пакет.

Поле опций (Options) - может появляться или не появляться в заголовке. Довольно-таки интересное поле. )
Опции могут быть двух типов - однобайтовые и многобайтовые. Многобайтовая опция состоит из полей "Тип опции", "Длина опции" и, собственно "данные опции". При этом "длина опции" - это общая длина поля, включая тип опции и поле длины.

Поле "Тип опции" содержит флаги - 1-й бит - нужно ли копировать опцию в каждый фрагмент пакета при фрагментации. 2-й бит - класс опции. 3-й бит - номер опции.

Классы опций - управляющая (0), зарезервировано (1), отладочная - (2) и опять зарезервированная (3).
Определены следующие номера опций:

Класс	Номер	Длина	Описание
0	0	-	Конец списка опций.
0	1	-	Поле-заполнитель, используемое для дополнения поля опций до кратной 32 бит границы заголовка
0	3	var	Включение мягкой маршрутизации от источника. Позволяет задавать маршрут пакета при его отправке.
0	9	var	Строгая маршрутизация от источника.
0	7	var	Запись маршрута. Включает запись адресов исходящих интерфейсов маршрутизаторов внутрь поля опций при пересылке пакетов.
2	4	var	Тайм-стамп опция. Включает запись временной метки на каждом маршрутизаторе, через который проходит пакет, при его пересылке.

Подробно об опциях можно почитать в RFC 791.

Динамическая маршрутизация

Естественно, вручную поддерживать таблицы маршрутизации в актуальном состоянии в крупной и часто изменяющейся сети очень сложно. Для автоматизации этого процесса еще начиная с 1980-х годов были разработаны протоколы динамической маршрутизации - средство, позволяющее маршрутизаторам самостоятельно получать информацию об имеющихся сетях и на основе нее строить свои таблицы маршрутизации.

Такой подход позволяет снизить затраты труда администраторов сетей. Но у него есть и недостатки:
1. Протоколы динамической маршрутизации создают дополнительную нагрузку на сеть - для обмена информацией роутеры используют полосу пропускания. Не так, чтобы сильно, но факт остается фактом.
2. Протоколы динамической маршрутизации снижают безопасность сети. Дело в том, что пакеты, которые передаются между маршрутизаторами можно как перехватить для изучения, так и подделать и в протоколах нет средства для защиты от этого. Таким образом, злоумышленники могут провести как DOS-атаку, отключив какой-либо маршрут, либо перехватыват траффик в сети, заменив адрес маршрутизатора на адрес ложного маршрутизатора, который можно использовать для перехвата пакетов.
3. Настройка и использование протоколов динамической маршрутизации налагают на администратора сети дополнительное требование - знание и понимание принципов работы этих протоколов.
4. Использование динамической маршрутизации может повысить нагрузку на процессоры маршрутизаторов, в случае некоторых протоколов - достаточно сильно.

Все протоколы динамической маршрутизации классифицируются по различным признакам:

Протоколы внутренней маршрутизации.
Такие протоколы заточены под работу внутри автономной системы (Автономная система - это независимо управляемая одной организацией сеть с собственной политикой маршрутизации внутри). К ним относятся RIP, OSPF, IS-IS, IGRP, EIGRP.

Протоколы внешней маршрутизации
Эти протоколы применяются для построения таблиц маршрутизации на пограничных маршрутизаторах, через которые автономная система подключается к магистральному каналу Internet.

Протоколы с поддержкой только классовой адресации
Эти протоколы не передают в информации о маршрутах маски сетей и поэтому уже вымерли. Иными словами, их нельзя применять в сетях с применением VLSM. (RIPv1, IGRP)

Протоколы с поддержкой бесклассовой адресации.
Противоположны протоколам с поддержкой только классовой адресации. Это RIPv2, OSPF, IS-IS, EIGRP

Протоколы, использующие в работе дистанционно-векторный алгоритм Беллмана-Форда.
Это RIP, IGRP, EIGRP
Это простые в реализации протоколы, маршруты в которых представляются векторами, направлением которых является адрес сети и следующий хоп, а длина зависит от числа хопов в сеть назначения.
После включения маршрутизаторы рассылают свою таблицу маршрутизации напрямую подключенным соседям, осуществляя таким образом заполнение их таблиц новыми маршрутами. Основной их недостаток - медленная "сходимость" сети. Т.е. полное обновление таблиц всех маршрутизаторов после изменений в сети может занимать продолжительное время. Этот недостаток исправлен в протоколе EIGRP, который, правда, стоит относить к "смешанным" протоколам, так как он все-таки отстраивает полную топологию связей в сети. Кроме того есть другой недостаток - они периодически рассылают полные таблицы маршрутизации, что в большой сети может вызвать интенсивное использование пропускной способности каналов связи.
Применение таких протоколов имеет смысл в сетях, построенных по звездообразной схеме, с наименьшим числом хопов между конечными маршрутизаторами, либо когда скорость сходимости не имеет значения. Либо если администраторы не имеют достаточной квалификации для понимания работы протоколов с отслеживанием состояний связей. =)

Протоколы, использующие алгоритм Дейкстры, или SPF, также известные как "протоколы с отслеживанием состояний связей"
Цель работы протокола - отстроить в памяти таблицу состояния связей в сети и, затем, на основании ее, используя SPF, отобрать кратчайшие маршруты во все известные сети, а затем добавить их в таблицу маршрутизации. Характеризуются низким использованием пропускной способности сети и быстрой сходимостью, но сильнее загружают процессор маршрутизатора из-за более сложных рассчетов при поиске оптимальных маршрутов. Такие протоколы - это OSPF, IS-IS.
Применять имеет смысл во всех случаях, в которых не подходят протоколы дистанционно-векторного типа.

Кроме них есть также path-vector протоколы, такие как BGP, но рассматривать их имеет смысл только администраторам автономных систем, так как внутри автономных систем и локальных сетей они не применяются.

Когда имеет смысл применять статическую маршрутизацию?
1. Когда сеть имеет топологию "hub-and-spoke", т.е. когда маршрутизаторы соединены вместе по схеме "звезда" и подключены к одному центральному маршрутизатору. В таком случае в их таблицах наиболее выгодно иметь только один маршрут по-умолчанию к центральному роутеру и уже на нем - статическую таблицу, обновляемую вручную.
2. Когда сеть небольшая и в ней очень редко происходят изменения топологии.

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

Каким должен быть Linux, чтобы он был похож на Windows?

Исходя из общения с довольно-таки утомленным за свою жизнь человеком, который имел несчастье познакомиться с Debian (и установить его уже, кажется, на 4-х машинах самостоятельно), сделал вот такие вот выводы:
1. Ядро не должно меняться годами.
Why: они не понимают, что такое ядро. Они не знают, где его взять. В гугле они находят kernel.org и спрашивают, как собирать ядра...
Why-not: От версии ядра слишком сильно зависит поддержка железа компьютера.

2. Ядро должно понимать минимально 99% всех железок, необходимых для установки и загрузки системы.
Why: Это нужно для выполнения (1)
Why-not: Если бы это было реально сделать, это было бы сделано. Но железки придумывают быстрее дистрибутивов, факт.
3. Драйвера нужно качать и устанавливать в систему двойным кликом мышки. Никаких пакетных менеджеров!
Why: ну тут все просто - это старая привычка - драйвер нужно найти и установить руками.
4. Точно так же должны устанавливаться приложения.
Why: аналогично (3)
5. Формат пакетов должен быть един и напоминать msi. Никаких зависимостей!
Why: опять аналогично (3)
6. Для любого существующего принтера/плоттера/сканера должен быть драйвер. Желательно на диске к принтеру. Как у гнусмасов. Или в системе - как у ХП. Эпсоны сосут, но к ним есть СМПЧ, поэтому сосет Cups без ppd к последним моделям.
Why: Купили Epson Stylus Photo R290...
7. Должна быть гуевая понятная штука, максимально повторяющая "Диспетчер устройств" в винде. Я знаю, что она есть, ее тупо не находят.
Why: а хз. )
8. Менеджера пакетов в системе быть не должно. Точка. Пользователи Windows не понимают, что это и зачем, и даже не понимают, чем это лучше, чем без него.
Why: "Я ведь совершенно не понимаю, что значат эти двадцать тысяч наименований пакетов. Что ставить? Даже если я ищу, оно мне предлагает 5-10 штук на выбор. Раньше было просто - записал тот же фотошоп на болванку - и, вот он..."
9. Должна быть дока, где "написаны все эти интересные команды в консоли..."
Why: с первого тыка я такое не нашел. Ну хоть Debian FAQ есть. А вменяемой доки по консоли на русском, где разжевано про получение информации про железо хотя-бы - нет.
10. Да, система не должна спрашивать, какие компоненты устанавливать при установке системы. Как Ubuntu. Или Windows.
Why: ну это тоже не просто. Откуда пользователю знать, что из 20k+ пакетов ему реально надо, а что - не надо ставить?

В общем, в целом ситуация сложная. Тяжело ломать старые стереотипы. =)