Windows 7 RDP shutdown

Выключение Windows 7 из сессии RDP.
Раньше достаточно было ввести в cmd: shutdown /s /f /t 0
Теперь придется добавлять причину выключения:
shutdown /s /f /t 005 /d P:0:0 /c "Plan"

Параметры QEMU для запуска в GNS3 Cisco ASA v8.4

Взято, в основном, отсюда: http://www.xerunetworks.com/2012/02/cisco-asa-84-on-gns3/
После того, как из бинарника ASA  вытащены ядро (vmlinuz) и корневая файловая система (initrd), чтобы в GNS3'е все правильно включилось, нужно добавить в настройках строки:
в раздел Qemu Options:
-vnc none -vga none -m 1024 -icount auto -hdachs 980,16,32
в раздел Kernel cmd line:
-append ide_generic.probe_mask=0x01 ide_core.chs=0.0:980,16,32 auto nousb console=ttyS0,9600 bigphysarea=65536
В противном случае, в открывшемся окне QEMU примонтированные IDE устройства начнут "мерцать", а сама ASA перезагружаться с выводом дампа отладки.

Windows Server Core ввод ключа и активация.

Взято отсюда: http://blogs.msdn.com/b/richin/archive/2008/04/09/activating-changing-product-key-on-windows-server-core-2008-after-installation.aspx

ввод ключа:
slmgr -ipk xxxxx-xxxxx-xxxxx-xxxxx-xxxxx
активация:
slmgr -ato

В целом, полезный скрипт (просмотреть возможности - ввод slmgr без параметров или /?, но он ругнется...).

Windows 7 разрешить ICMP echo (ответы на ping'и)

По умолчанию встроенный файрол блокирует ответы сетевого интерфейса на пинги. Чтобы не отключать файр полностью, добавим некоторые (не все) типы ICMP:
1. из Панель управления\Система и безопасность\Брандмауэр Windows\Дополнительные параметры, добавим правило для входящих подключений,
2. Создать правило \ Настраиваемое \ Все программы \ Тип протокола = ICMPv4, Параметры протокола ICMP \ Настроить \ Определенные типы ICMP:
- Пакет слишком велик (очень важно для трафика на протоколе GRE, например, PPTP),
- Объект назначения не доступен,
- Эхо-запрос,
- Превышено время.
3. Определяем правило для Любых адресов \ Разрешаем подключения \ Применяем ко всем профилям
4. Сохраняем правило, например, под именем "ICMP-essentials"
Уф, все...

Cisco Frame Relay switching Connect feature.

В процессе изучения Frame Relay технологии попробовал сэмулировать сеть с парой FR свичей и 4мя клиентами (3 спока завязываются на хаб). Ниже схема включения (использовался IOU v3 от flyxj.cn):

Шнурки между двумя Frame Relay Switch'ами (FRS1 / 2) объединены в Multilink Frame Relay интерфейс - MFR0. Рутер R01 - хаб.
Получилось примерно так:
FRS1
FRS1:
interface MFR0
 no ip address
 encapsulation frame-relay IETF
 no keepalive
 frame-relay lmi-type ansi
 frame-relay intf-type nni
!
interface Serial2/0
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/1
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/2
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
interface Serial2/3
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!        
connect R01-CE1 Serial2/2 102 Serial2/3 203
connect R1-CE2 Serial2/2 108 MFR0 207
connect R1-R6 Serial2/2 106 MFR0 702
---
FRS2:
interface MFR0
 no ip address
 encapsulation frame-relay IETF
 no keepalive
 frame-relay lmi-type ansi
 frame-relay intf-type nni
!
interface Serial2/0
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial2/1
 no ip address
 encapsulation frame-relay MFR0
 serial restart-delay 0
 no arp frame-relay
!
interface Serial3/0
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
interface Serial3/2
 no ip address
 encapsulation frame-relay IETF
 serial restart-delay 0
 frame-relay lmi-type ansi
 frame-relay intf-type dce
!
connect CE2-R1 Serial3/2 708 MFR0 207
connect R6-R1 Serial3/0 607 MFR0 702
По уму, здесь нужно поменять serial интерфейсы к клиентам (которые inf-type dce) на субинтерфейсы и включить clock rate, ну да задача была разобраться в connect feature...

JunOS Olive установка в Virtual Box, апгрейд.

На просторах Интернета полно статей по установке JunOS поверх фряхи.
Например, полезняшки здесь:
http://habrahabr.ru/post/111974/
здесь:
http://pauldotcom.com/2011/05/virtualizing-junos-on-vmware.html
здесь:
http://www.packetmischief.ca/2011/03/24/installing-olive-10-4r1-under-vmware/
и, конечно, здесь:
http://juniper.cluepon.net/index.php/Olive
В целом, алгоритм ясен:
- ставим фряху с большим разделом /var,
- достаем в "труднодоступных" местах jinstall-xxx.tgz,
- распаковываем и правим ряд параметров,
- пакуем с правками тарболл взад и,
- ставим во фре, как обычный пакет pkg_add.
В процессе изучения сабжа выяснилось несколько моментов:
- не каждая фряха одинаково полезна, наилучшие результаты достигались на версии 4.11 (это при живущей уже 9ке!),
- вопреки расхожему мнению, jinstall тарболл извлекается и из iso'шников,
- патчить / править тарбол можно на любой машине, где есть tar.
Начнем с подготовки виртуалки:
- выделяем 768Мб ОЗУ,
- выделяем IDE хард на 6Гб,
- отключаем звук, USB,
- создаем serial host pipe для COM1, пусть на /tmp/junos9com1
Собственно, скопипастенные действия для JunOS 9.6:
cd /var/tmp
mkdir jinst ; cd jinst ; tar xvzf ../jinstall-9.6R1.13-domestic-olive.tgz
# rm *.md5 *.sha1 *.sig
mkdir domestic ; cd domestic ; tar xvzf ../jbundle-9.6R1.13-domestic.tgz
rm *.md5 *.sha1 *.sig
mkdir pkgtools ; cd pkgtools ; tar xvzf ../pkgtools.tgz
cd pkg ; rm *.md5 *.sha1 *.sig ; cd ..
все распаковано и все контрольные суммы прибиты, теперь подменяем скрипт проверки (обращение будет возвращать код true)
cp /usr/bin/true bin/checkpic
пакуем все обратно, стирая созданные каталоги:
tar cvzf ../pkgtools.tgz *
cd .. ; rm -rf pkgtools
tar cvzf ../jbundle-9.6R1.13-domestic.tgz *
cd .. ; rm -rf domestic/
tar cvzf ../jinstall-9.6R1.13-domestic-no-checkpic.tgz *
cd .. ; rm -rf jinst/
В результате получаем тарболл jinstall-9.6R1.13-domestic-no-checkpic.tgz, который и будет установлен:
pkg_add jinstall-9.6R1.13-domestic-no-checkpic.tgz
перезагружаемся - reboot, параллельно можно открыть консольный вывод, чтобы видеть процесс установки JunOS, или, как рекомендуемый вариант, поправим запись:
chmod +w /boot/loader.conf
vi /boot/loader.conf
находим запись console="comconsole" и исправляем ее на
    console="vidconsole"
если этого параметра нет - просто дописываем в конец файла и сохраняем.
Да, консольный вывод (используя socat), мне нравится такой вариант:
screen sudo socat /tmp/junos9com1 -
После всех проделанных процедур, получаем виртуальный рутер с ПО для Juniper M / T / MX Series.
В данной серии оборудования функционал распределяется по аппаратным модулям, ОС же играет роль центра управления, так что огромное количество фич будет не доступно, например, для работы NAT необходим service-interface (sr-0/0/0.0). Без него настройки NAT просто не применятся, кстати, в данной серии девайсов настройка NAT осуществляется через edit services nat.
Пошарив по задворкам тырнета наткнулся на пару утверждений, что для Оливки самый правильный JunOS - тот, который для J-Series (JSR?) рутеров - типа там у них все софтово творится, так что на эмуляторе пойдет кучеряво.
Надыбал  junos-jsr-10.3R1.9-domestic.tgz, который сам по себе на фряху не ставится, но им можно проапгрейдить имеющийся 9.6 JunOS.
Правим тарбол практически аналогично, с добавками (для 10й и старших версий) - везде, где видим файлы +INSTALL и +REQUIRE находим в них строки проверки архитектуры и подменяем (в vi):
check_arch_compatibility()
{
    #re_name=`/sbin/sysctl -n hw.re.name 2>/dev/null`
    re_name='olive'
    if [ -z "$re_name" ]; then
        Error "hw.re.name sysctl not supported."
    fi
комментируем строку re_name... и создаем свою с именем "olive", сохраняем все правки и пакуем обратно.
Теперь процедура обновления, в моем случае, патченный тарболл находится на локальном ftp серваке, так из cli выполняем:
request system software add unlink no-copy ftp://_username_:_password_@_ip_ftp_server_/Software/Juniper/junos-jsr-10.3R1.9-domestic-patched.tgz
Дожидаемся примерно таких строк:
JUNOS 10.3R1.9 will become active at next reboot
cat: /packages/junos-10.3R1.9-domestic.sha1: No such file or directory
Saving state for rollback ...
Removing /var/tmp/junos-10.3R1.9.tgz
и перезагружаем виртулку:
request system reboot
Новый рутер начал определяться уже как J4300, однако при настройке NAT (эта проверка настоятельно рекомендуется тем, кто планирует использовать сабж, как пограничное устройство), опять постиг облом:
error: usp_ipc_client_open: failed to connect to the server after 1 retries
поиск по ошибке указал на то, что в девайсе не хватает модуля, что проверка шасси и подтвердила:
show chassis fpc             
                     Temp  CPU Utilization (%)   Memory    Utilization (%)
Slot State            (C)  Total  Interrupt      DRAM (MB) Heap     Buffer
  0  Empty          
  1  Empty          
  2  Empty          
  3  Empty          
  4  Empty          
  5  Empty          
  6  Empty          
Кстати, здесь NAT настраивается через edit security nat...

Привилегированный доступ к машинам Virtual Box для подключения к среде GNS3

Для создания интерфейсов подключения GNS3 запускается с правами суперпользователя (параметры запуска предваряются вариантом sudo для графических приложений - gksudo /home/_username_/GNS3-0.8.2-BETA-src/gns3.pyw). Аналогично для подключения vbox хостов приложению Virtual Box также необходимо запускаться через gksudo, при этом, файл со списком настроенных виртуалок будет использовать путь /root/.VirtualBox/VirtualBox.xml, то есть при старте мы не увидим ни одной машины. Для исправления:
бэкапим существующий файл
sudo cp /root/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml.backup
копируем не-sudo файл )из домашнего каталога
sudo cp /home/_username_/.VirtualBox/VirtualBox.xml /root/.VirtualBox/VirtualBox.xml
Теперь, машины, созданные не с использованием путей по-умолчанию, будут полностью доступны и работоспособны, а те, что создавались с дефолтными параметрами, будут ссылаться на конфиги и vHHD в каталогах
src="Machines/_виртуалка_", эти сокращенные пути по факту: /home/_username_/.VirtualBox/Machines/, так что это необходимо поправить в файле
sudo vim /root/.VirtualBox/VirtualBox.xml
в разделе MachineRegistry