ip sla 2 канала интернет (один основной и широкий)

конфиги интерфейсов на провайдеров
interface GigabitEthernet0/0
ip address 21.18.173.89 255.255.255.240
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
ip policy route-map silver
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/1
ip address 18.13.23.34 255.255.255.248
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
ip policy route-map golden
duplex auto
speed auto
route-map нужны для ната поскольку если 2 канал нат и использование access-list не будет коректно работать посколько циска будет терятся через какой интерфейс натить конкретную сессию. Конфиг интерфейса локальной сети
interface Vlan1
description $ES_LAN$
ip address 192.168.41.1 255.255.255.0
ip nat inside
ip virtual-reassembly
Собственно конфиги route-map для провайдеров
route-map golden permit 10
 match ip address 110
 match interface GigabitEthernet0/1
!
route-map silver permit 10
 match ip address 110
 match interface GigabitEthernet0/0
при этом access-list
access-list 110 permit ip 192.168.0.0 0.0.255.255 any
и конфиг ната
ip nat inside source route-map golden interface GigabitEthernet0/1 overload
ip nat inside source route-map silver interface GigabitEthernet0/0 overload
собственно настройка ip sla (одна запись поскольку мы будет отслеживать основной канал только при его поднятии и падении будет удалятся или появляться маршрут по умолчанию - маршруты будут приведены дальше)
ip sla 1
 icmp-echo 20.85.18.13 source-interface GigabitEthernet0/0
 timeout 1000
 threshold 40
 frequency 3
ip sla schedule 1 life forever start-time now
теперь конфиг трака для ip sla
track timer interface 5
!
track 1 stub-object
!
track 100 ip sla 1 reachability
 delay down 15 up 10
и собственно маршруты на провайдеров
ip route 0.0.0.0 0.0.0.0 21.18.173.77 track 100
ip route 0.0.0.0 0.0.0.0 18.13.23.33 5
первый на основной канал и зависит от состояния трака (то есть появляется или исчезает в зависимости от состояния канал), 2 статический с метрикой 5 (метрика нужна для того чтобы при восстановлении основного канал опять маршрутом по умолчанию стал основной провайдер, если метрику не поставить основной маршрут не меняется поскольку если у маршрутов одинаковые метрики то никто из них не имеет приоритета и даже при возвращения основного маршрута дефолтом остается маршрут на беккапного провайдера и канал не возвращается на основного провайдера с широким доступом)

Примеры sql запросов

1). замена части строки (столбцы homedir, maildir - в низ производится замена kiev на kot.kiev.ua)
UPDATE users set homedir=replace(homedir, 'kiev', 'kot.kiev.ua'),  maildir=replace(maildir, 'kiev', 'kot.kiev.ua')  where homedir like '%kiev%';

Флешка, которая не дает вирусам писать autorun.inf

Диск подключился с буквой E

используя универсальные пути создаем нужный каталов autorun.inf и в нем com1. Стандартным средствами винды нельзя ни создать ни удалить такой каталой и вирусы не могу его перзаписать поэтому. То есть они не могут замутить свой автозапуск, а максимум только могут сделать свой каталог с своим телом и тольку ноль - ауторан нет, запуска тела вируса нет, его можно просто удалить. Не нужно забывать что их каталоги скрыты поэтому нужно на забывать включать показывать скрытые файлы, данные каталоги autorun.inf\com1 desktop.ini\com1 я тоже слелаю скрытыми и системными. Также важно что вирус часто палится когда он есть на пк, что он не может перезаписать autorun.inf, но делает при этом его видимымым, этим он палится что он живет на пк.

Команды выполняются Пуск - Выполнить - cmd - Enter или OK

1). Создание файлов

mkdir \\.\E:\autorun.inf\com1

mkdir \\.\E:\desktop.ini\com1

если вдруг захотите удалить (врятли конечно)

rmdir \\.\E:\autorun.inf\com1

rmdir \\.\E:\desktop.ini\com1

2). Делаем их скрытыми и системными

attrib +s +h E:\autorun.inf

attrib +s +h E:\desktop.ini

Cisco and vlan которые могут то работать то нет

Они когда-то были зарезервированы и поэтому на одних IOS они работают на других нет

1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsup

Повышение безопасности домена

1). В групповых политиках для машин пользователей
1.1). Через реестр
По умолчанию - 10
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\winlogon. Ключ CachedLogonsCount (если нет создать REG_SZ тип) = 0 сделать.
Через груповые политики
1.2) Через груповые политики
Конфигурация компьютера, Конфигурация Windows, Параметры безопасности, Локальные политики, Параметры безопасности, Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена) = 0
Брутить эти хешированные пароли и логины могут Cain&Abel (локально) и PWDumpX (удаленно).
Но поскольку при разблокировке станции (выход из скринсейвера, если он требует логин пароль, или станция заблокирована вручную) нужны логин и пароль кешированнию подвергается текущая сессия в памяти. Если используется кеширование доменные контролер не используется, для его использования при разблокировке
Конфигурация компьютера, Конфигурация Windows, Параметры безопасности, Локальные политики, Параметры безопасности, Интерактивный вход в систему: требовать проверки на контроллере домена для отмены блокировки - вкл.
2). Отключение отражения (Smb relay - бюлетень MS08-068). Апдейты отключают рефлексию на хост инициировавший соединение соединение (но это не откл. рефлесию на другие хосты и по другим протоколам). "Подписывание SMB" к сожалению по умолчанию откл., только на контролере домена (начиная с Win2000) вкл.
Клиент
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (с согласия сервера)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными с клиентами (если возможно)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters
EnableSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. В Windows Server 2003, Windows XP и Windows 2000 значение по умолчанию – 1 (включен).
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (всегда)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными с клиентами (всегда)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\LanManWorkstation\Parameters
RequireSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. В Windows Server 2003, Windows XP и Windows 2000 значение по умолчанию – 0 (необязательный).
Сервер
Групповая политика «Клиент сети Microsoft: использовать цифровую подпись (с согласия клиента)» в Windows Server 2003 и Windows XP и групповая политика «Использовать цифровую подпись при обмене данными между серверами (если возможно)» в Windows 2000 сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
EnableSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. На контроллерах домена под управлением Windows Server 2003 и Windows 2000 значение по умолчанию – 1 (включен). На контроллерах домена под управлением Windows NT 4.0 значение по умолчанию – 0 (отключен).
В Windows Server 2003 и Windows XP политика «Сервер сети Microsoft: использовать цифровую подпись (всегда)»
и в Windows 2000 политика «Использовать цифровую подпись при обмене данными между серверами (всегда)» сопоставлены со следующим разделом реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters
RequireSecuritySignature (REG_DWORD) 1 (вкл.)
Примечание. На контроллерах домена под управлением Windows Server 2003 и Windows 2000 значение по умолчанию – 1 (обязательный). На контроллерах домена под управлением Windows NT 4.0 значение по умолчанию – 0 (необязательный).
(http://support.microsoft.com/kb/887429/ru)

rpm - использование (ньюансы)

1). Верификация

# rpm -V util-linux-2.12q-26

S.5....T /bin/arch

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

s означает изменение размера файла,
5 – нарушение сигнатуры md5 файла,

T – изменение времени последней модификации (то есть времени копирования файла в систему в нашем случае).

2). В режимах установки-удаления довольно часто возникает необходимость воспользоваться опциями --nodeps или --force. Первая позволяет установить (удалить) пакет независимо от того, удовлетворяются ли все его зависимости, вторая – установить пакет даже в том случае, если в системе имеются файлы более свежих версий. Некоторый интерес представляют опции --aid, которая автоматически удовлетворит возникающие зависимости и --test, которая и означает тестирование операций, то есть весь вывод о возникающих проблемах будет осуществлен, но реальных операций не производится. Очень удобно моделировать поломку системы в результате каких-либо действий.

3). # rpm -q --queryformat %{DESCRIPTION} <имя пакета>

выведет описание пакета, а команда

# rpm -q --queryformat %{DISTRIBUTION} <имя пакета>

– название дистрибутива, в составе которого находится пакет.

Причем замена -q на -qp позволит ту же самую информацию получить от rpm-файла не установленного в систему пакета. Можно получить список только конфигурационных файлов пакета, или только файлов документации, или только файлов, содержащих в имени регулярное выражение, то есть в принципе что угодно.

4). Формат rpm-пакета.

Формат пакета состоит из бинарного заголовка и cpio-архива, который содержит бинарные файлы в таком дереве каталогов, в каком они будут находится в системе после установки пакета. Файловый менеджер mc понимает множество всяких архивов, и в том числе – упаковку rpm. Если в панели mc выделить rpm-пакет и нажать ввод, мы увидим псевдофайловую систему, состоящую из следующих компонентов: каталога INFO, архива CONTENTS.cpio, того самого, содержащего бинарные файлы, файла HEADER и псевдоскриптов INSTALL и UPGRADE. В каталоге INFO содержатся файлы, имена которых соответствуют именам полей spec-файла, содержимое – значениям полей. Файл HEADER – по сути то же самое, только в одном файле. Ссылки INSTALL и UPGRADE соответствуют командам rpm -ih <имя пакета> и rpm -Uh <имя пакета>. То есть, если на них нажать, эти действия и произойдут.

В реальном формате никакой файловой системы нет. Просто mc умеет по-своему интерпретировать бинарный заголовок пакета, за что его разработчикам большой респект.

При желании можно выделить cpio-архив из всего пакета. Для этого существует утилита rpm2cpio.

5). Соберем пакет.

В rpm версии v.4 режим сборки пакета оформлен в виде отдельной утилиты – rpmbuild. Воспользуемся самым эффективным методом изучения технологии, то есть, соберем модельный rpm-пакет. Нет и вопроса, что должна делать программа, которую мы упакуем в rpm. Она должна говорить: «Hello, world!»!

В rpm-based дистрибутивах существует специальное дерево каталогов, предназначенное исключительно для сборки пакетов. Оно лежит в /usr/src (в Suse Linux – в /usr/src/packages) и содержит каталоги BUILD, RPMS, SOURCES, SPECS, SRPMS. Предназначены они соответственно для хранения временных каталогов сборки, собранных бинарных rpm, исходного кода, хранения файлов спецификации, собранных src.rpm-пакетов. Src.rpm содержат исходный код и spec-файлы и предназначены для пересборки на целевых машинах с целью лучшей адаптации к архитектуре и системному окружению этих машин. Для сборки нам потребуется исходный код программы, который традиционно упаковывается в tar.gz или в tar.bz2 и spec-файл. Spec-файл для rpm примерно то же, что Makefile для утилиты make. Это подробнейший сценарий того, что должно происходить при сборке со всеми необходимыми определениями и служебными полями. Итак, за дело.

Создадим текст программы на С. Файл назовем hi.c и поместим его в каталог SOURCES. Отредактируем содержание файла в любимом текстовом редакторе следующим образом:

#include

int main(int argc, char **argv)
{
fprintf(stdout,"Hello, World!\n");
return 0;
}

Не забудем пустую строку в конце файла. Запакуем исходный код в tar.gz (команду отдаем, находясь в каталоге /usr/src/packages/SOURCES):

# tar cvfz ./hi-0.1.tar.gz ./hi.c

Далее spec-файл. По сути дела, умение создавать хорошо пересобираемые rpm-пакеты – это умение писать spec-файлы. Они имеют сложную структуру, подробности которой рассмотреть не представляется возможным в журнальной статье, поэтому обсудим главное. Файл делится на секции, каждая секция отвечает за свою часть работы. Создадим файл под именем hi.spec в каталоге SPECS и наполним его следующим содержанием:

Summary: Приветствующая утилита.
Name: hi
Version: 0.1
Release: 1
Copyright: GPL v.2
Group: Tests
Source:%{name}-%{version}.tar.gz
BuildRoot: /tmp/hi
%description
Тестовая программка для вывода приветствия.
%prep
%setup -c hi
%build
gcc -o hi hi.c

%install
mkdir -p $RPM_BUILD_ROOT/usr/local/bin
cp hi $RPM_BUILD_ROOT/usr/local/bin
%clean
rm -rf $RPM_BUILD_ROOT
%files
/usr/local/bin/hi
Проанализируем функции отдельных секций spec-файла.

Все, что написано до строки %prep, составляет секцию introduction. Она содержит описания, определения версий и релизов, корень сборки и другую служебную информацию. Значения всех этих полей используются через имена полей в качестве переменных при сборке и включаются в одноименные поля бинарного заголовка rpm-пакета.

Секция prep отвечает за подготовку исходного кода к сборке. В нашем примере секция содержит строку %setup -c hi, которая вызывает макрос RPM. Макрос, в свою очередь, распаковывает исходный текст Си из архива.

Секция build содержит инструкции по сборке. В данном случае мы указали имя выходного бинарного файла – hi. Если проект большой, как правило должен быть сгенерирован Makefile, поэтому секция может содержать нечто подобное:

./configure CXXFLAGS=-03 –prefix=$RPM_BUILD_ROOT/usr

make

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

rm -fr $RPM_BUILD_ROOT

make install

В нашем проекте нет Makefile, поэтому мы указали все непосредственно.
Секция clean содержит команды удаления каталогов сборки.
Секция files – список файлов проекта.

Итак, у нас имеется исходный код в виде tar.gz-архива и spec-файл. Больше для сборки пакета ничего не требуется. Естественно, в системе должны быть установлены средства разработки.

Для сборки пакета вызываем утилиту rpmbuild с ключом -b. Второй символ набора ключей означает цель сборки. Опция -a указывает на необходимость собрать как rpm-пакет, так и src.rpm. Укажем также целевую архитектуру. Находясь в каталоге SPECS, отдадим следующую команду:

rpmbuild -ba --target i586 ./hi.spec

Если в последней строке консольного вывода Вы увидите: + exit 0, значит все прошло как надо. В каталоге RPMS/i586 должен обнаружиться файл

hi-0.1-1.i586.rpm, в каталоге SRPMS – файл hi-0.1-1.src.rpm. Воспользуемся уже имеющимися знаниями, и установим пакет hi в систему:

# cd /usr/src/packages/RPMS/i586

# rpm -Uhv ./hi-0.1-1.i586.rpm

Теперь, если Вы скажете в консоли:

$ hi

получите ответ: Hello, World!
Для установки src.rpm-пакета воспользуйтесь командой:

# rpm -i /путь к каталогу/hi-0.1-1.src.rpm

При этом в систему скопируются исходный код и spec-файл (в то самое дерево каталогов для rpm-сборки). Если нужно просто собрать бинарный пакет, достаточно сказать:

# rpmbuild --rebuild /путь к каталогу/hi-0.1-1.src.rpm

Трюки и советы по командной строке

1). Количество линий в файле
sed -ne '$=' ~/.bashrc
2). Сокращенный вывод при подсчете размера текущего каталога (оставляем только подкаталоги)
du -h . | grep -v '/.*/' | sort -n
3). календарь за месяц
cal 01 2011
4). uptime графически
uptime | awk '{while($3--) a=a"="; print "|" a ">"}'
5). к какому пакету относится файл txt1
fedora# rpm -qf txt1
debian# dpkg -S txt1
gentoo# equery belongs txt1
freebsd# pkg_info -W txt1
freebsd# pkg_info -E txt1