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

Virtual Box ошибка выключения и запуск в среде GNS3

При использовании Oracle Virtual Box версии 4.1.8 было замечено два глюка:
1. при выключении питания, если в работе использовались виртуалки с vboxnetX адаптерами, это выключение замораживалось с ошибкой unregister_netdevice waiting for vboxnetX to become free
2. при тестировании подключения виртуальных машин Virtual Box в среде GNS3 выдавалась ошибка vboxapi module cannot be loaded
Обе эти проблемы решались сначала полным удалением существующего приложения (4.1.8) и новой установкой пакета версии 4.1.20, собранного конкретно под текущую версию ОС - не All distributions! В моем случае, это пакет для Ubuntu 12.04 LTS ("Precise Pangolin")  i386 (http://download.virtualbox.org/virtualbox/4.1.20/virtualbox-4.1_4.1.20-80170~Ubuntu~precise_i386.deb).
В результате 1й глюк успешно побеждается, 2й же немного видоизменяется - при тесте выдается ошибка failed to start xdotool, но это чинится установкой этих самых тулзов:
sudo apt-get install xdotool

Применение патча 0029-Integrating-Dynamips-and-GNS3-UDP-tunnels-Patches.patch для QEMU 1.0 в Ubuntu 12.04

Без данного патча подключить в GNS3 (в моем случае это версия GNS3-0.8.2-BETA) такие полезняшки как Cisco ASA и JunOS (Olive) router можно, но сложно. На просторах Интернета куча статей и HowTo по данному вопросу, однако коротко и ясно все решение было изложено у коллеги: http://kaktyc.wordpress.com/2012/05/18/запуск-qemu-хоста-в-gns3/.
В процессе использования приведенных инструкций проявилась и парочка граблей. В целом, порядок действий такой:
- выделяем каталог под сборку пакета - mkdir gns3-qemu
- проверяем версию QEMU на нашей машине (грабли №1 - нужна версия 1.0)
стоит обратить внимание, что просто команды qemu (как было раньше) уже нет, варианты:
qemu [Tab]
qemu-ga             qemu-ifup           qemulator           qemu-system-i386   
qemu-i386           qemu-img            qemu-launcher       qemu-system-x86_64 
qemu-ifdown         qemu-io             qemu-nbd            qemu-x86_64
$ qemu-i386 -version
qemu-i386 version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
$ qemu-system-i386 -version
QEMU emulator version 1.0 (qemu-kvm-1.0), Copyright (c) 2003-2008 Fabrice Bellard
Если версия ниже - необходимо проапгрейдиться до 1.0, для "правильной" версии устанавливаем девелоперские инструменты и сорцы,
- sudo apt-get build-dep qemu-kvm ,
- apt-get source qemu-kvm ,
- благодаря ссылке коллеги kaktyc'а о том, что Gentoo'шный патч подходит, качаем его:
wget -c http://dev.gentoo.org/~lu_zero/distfiles/qemu-1.0-patches.tar.xz
там также есть патчи qemu-1.1.0-patches.tar.xz и qemu-1.1.0-r1-patches.tar.xz - более поздние, но они нам не подходят,
- распаковываем и применяем нужный патч на сорцы:
tar xvJf qemu-1.0-patches.tar.xz
 cd qemu-kvm-1.0+noroms/
 patch -p1 < ../patches/0029-Integrating-Dynamips-and-GNS3-UDP-tunnels-Patches.patch
- теперь создаем deb пакет с примененным патчем:
dpkg-buildpackage -b -uc -nc -j4
- в результате будут созданы два! deb пакета (в моем случае, архитектуры i386, у коллеги amd64):
qemu_1.0+noroms-0ubuntu14.1_i386.deb и qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
Первый содержит:
dpkg --contents qemu_1.0+noroms-0ubuntu14.1_i386.deb
drwxr-xr-x root/root         0 2012-09-02 00:55 ./
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/doc/
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/share/doc/qemu/
-rw-r--r-- root/root     19020 2012-09-02 00:48 ./usr/share/doc/qemu/changelog.Debian.gz
-rw-r--r-- root/root      4079 2012-09-02 00:48 ./usr/share/doc/qemu/copyright
то есть только раздел doc, а вот второй:
dpkg --contents qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
...
drwxr-xr-x root/root         0 2012-09-02 00:55 ./usr/bin/
-rwxr-xr-x root/root     13720 2011-12-04 14:38 ./usr/bin/kvm_stat
-rwxr-xr-x root/root    987712 2012-09-02 00:55 ./usr/bin/qemu-i386
-rwxr-xr-x root/root    416616 2012-09-02 00:55 ./usr/bin/qemu-io
-rwxr-xr-x root/root   1164148 2012-09-02 00:55 ./usr/bin/qemu-x86_64
-rwxr-xr-x root/root   3734788 2012-09-02 00:55 ./usr/bin/qemu-system-x86_64
-rwxr-xr-x root/root   3566468 2012-09-02 00:55 ./usr/bin/qemu-system-i386
-rwxr-xr-x root/root    124552 2012-09-02 00:55 ./usr/bin/qemu-ga
...
Его-то нам и нужно установить:
- sudo dpkg -i qemu-kvm_1.0+noroms-0ubuntu14.1_i386.deb
В результате патч применится.
Непосредственно в самом GNS3 для запуска QEMU в разделе Edit / Preferences / Qemu / General Settings / Path to Qemu указываем не просто qemu, а qemu-system-i386 (Грабли №2).
Теперь тест - Test Settings пройдет успешно.

Проброс портов через SSH Линукс клиентом и Putty

В мемориз.
В "родном" Linux ssh client делается так:
ssh -L 44433:192.168.75.2:443 -L 54433:192.168.75.200:443 -L 43389:192.168.75.4:3389 username@ssh_gateway -N
в данном случае это не только port-forward, но еще и port-trigger (позднее мы будем коннектиться на localhost по портам, первым в записях -L).
В Putty похожее также реализовано (например, здесь: http://www.virtuallifestyle.nl/2010/03/tunneling-a-vsphere-client-connection-over-ssh/ отличное описание проброса нужных портов для VMWare Client'а с учетом того, что конкретно VMWare клиенту не следует устанавливать переключение портов - port-trigger, так как ему нужны свои родные порты 443,902 и 903). В целом, для Putty действия такие:
- новая ssh сессия (Session) - указываем ssh хост (будет ssh gateway),
- в разделе Connection / SSH / Tunnels / Add new forwarded port: указываем Source Port как Local (можно также указать, что он IPv4 или оставить Auto), в Destination Указываем адрес и порт на которые нужно будет пробросить коннекшен вида ip_server:port,
- добавляем Add это в таблицу Forwarded Ports,
- можно вернувшись в раздел Session сохранить (поименовав) ее.

Создание ярлыков запуска (Launcher'ов) в Ubuntu 12.04 с Gnome Shell

В мемориз.
В Ubuntu 12.04 (даже с Gnome Shell'ом) создание Launcher'ов по контекстному меню больше не работает, на рабочем столе из него можно только создавать файлы/папки, да "копипастить" всякое. Теперь эта ланчеры создаются в приложении alacarte (sudo apt-get install alacarte) - оно же Applications / System Tools / Preferences / Main Menu
Там создаем новый item, а дальше все как на обычном Launcher'е.

Установка и базовая настройка SliTaz 4.0

В 4й версии был убран установочный скрипт slitaz-installer, при этом способ установки сабжа из консоли стал не совсем понятен. После недолгих поисков, удалось частично понять новую идеологию дистрибутива. Итак,

Установка
tazinst new tazinst.conf
создается в текущем каталоге файл tazinst.conf с параметрами установки. Они описагы в доке:
http://hg.slitaz.org/slitaz-tools/raw-file/6e8c38a0aee3/doc/tazinst.en.html

...
 The setup file contains the following variables:

    The variables describing the installation source:
        *INST_TYPE: the type of media containing the SliTaz source files, either: cdrom (SliTaz LiveCD), usb (SliTaz LiveUSB), iso (ISO image of SliTaz), web (ISO image on the Web), weboot, ex: INST_TYPE=web
        SRC_FILE: the name of the source file containing SliTaz. It depends on the type of support:
            cdrom (SliTaz LiveCD): unused
            usb (SliTaz LiveUSB): name of the partition on the host USB device, ex: SRC_FILE=/dev/sdb1
            iso (ISO image of SliTaz): name of the ISO file, ex: SRC_FILE=~/slitaz.3.0.iso
            web (ISO image on the Web): name of the URL, ex: SRC_FILE=http://mirror.slitaz.org/iso/cooking/slitaz-cooking.iso. Note that 3 URLs are predefined: 'stable', 'cooking, 'rolling', ex: SRC_FILE=cooking downloads the latest cooking available from the web
            weboot: unused

    The variables describing the target partition:
        *TGT_PARTITION: the name of the target partition SliTaz will install to or update, ex: TGT_PARTITION=/dev/hda3
        TGT_FS: if this variable is entered, the target partition will be formatted in the file system specified, otherwise the partition will be cleaned and /home will be preserved, ex: TGT_FS=ext3
        TGT_HOME: this variable indicates if need be, the name of the partition to receive the /home directory, ex: TGT_HOME=/dev/hda5
        TGT_HOME_FS: if this variable is entered, the home partition will be formatted in the file system specified, ex: TGT_HOME_FS=ext2

    The system settings:
        TGT_HOSTNAME: name of the system, ex: TGT_HOSTNAME=hd-slitaz, by default TGT_HOSTNAME=slitaz
        TGT_ROOT_PWD: superuser password, ex: TGT_ROOT_PWD=toor, by default TGT_ROOT_PWD=root
        TGT_USER: user name, ex: TGT_USER=toto, by default TGT_USER=tux
        TGT_USER_PWD: user password, ex: TGT_USER_PWD=titi, by default TGT_USER_PWD=tux

    The boot loader (bootloader) configuration variables:
        TGT_GRUB: install the GRUB bootloader (yes or no), ex: TGT_GRUB=yes, by default TGT_GRUB=no
        TGT_WINBOOT: if this variable is entered, it indicates the partition containing Windows© to implement a dual-boot. It can also be set to 'auto', in this case the dual-boot will be on the first partition Windows© detects, ex: TGT_WINBOOT=auto

Note that only variables preceded by a asterisk are mandatory, others are optional. Thus a minimal setup file can be:

INST_TYPE=cdrom
TGT_PARTITION=/dev/hda3

This file will install SliTaz on /dev/hda3 formatting the partition from a LiveCD.
...

В моем случае хватило указать:
INST_TYPE=cdrom
TGT_PARTITION=/dev/sda1
TGT_FS=ext3
TGT_HOSTNAME=slitaz4-test
TGT_ROOT_PWD=***
TGT_USER=My
TGT_USER_PWD=***
TGT_GRUB=yes
Теперь запускаем установку
tazinst install tazinst.conf
после окончания убеждаемся, что Grub поставился и перезагружаемся reboot
--
Настройка сети - правка файла /etc/network.conf
INTERFACE="eth0"
DHCP="no"
STATIC="yes"
IP="172.17.17.20"
NETMASK="255.255.255.0"
GATEWAY="172.17.17.1"
DNS_SERVER="172.17.17.1"

После правки /etc/init.d/network.sh restart
--
Для активации ssh сервера (здесь это dropbear) дописываем его в автозапуск (под root'ом):
vi /etc/rcS.conf
 RUN_DAEMONS="...httpd dropbear"
:wq
запускаем сервис (ключи сгенерятся автоматом)
/etc/init.d/dropbear start
--
Установка пакетов (sudo, vim, screen...)
Помощь по системе управления пакетами: http://doc.slitaz.org/ru:handbook:packages
Help самой проги - tazpkg usage
# tazpkg recharge
# tazpkg get-install sudo
# visudo
для My
$ sudo tazpkg get-install screen vim fail2ban
--
Удаленное web управление - Tazpanel
для доступа извне правим конфиг:
sudo vim /etc/slitaz/httpd.conf (! не спутать с /etc/httpd.conf!)
добавляем после A:127.0.0.1
A:172.17.17. (разрешаем подсеть - точка в конце нужна!)
Сохраняем, перезагружаем панель
sudo /etc/init.d/tazpanel restart
теперю появится доступ для пользователя root на адресе хоста на порту 82:
http://172.17.17.20:82

Software Ip KVM (KeyboardVideoMouse).

В процессе поиска аппаратного KVM'а также были замечены софтовые решения для управления несколькими компами (с уже установленными ОС) по сети с одной клавы / мыши, оставаясь при этом относительно прозрачными - явно не запускаются RDP / VNC клиенты.
Итак по порядку.

MaxiVista
http://www.maxivista.com/kvm-software.htm
Вкратце описалово:
... Simply move the mouse cursor to the monitor of the PC you would like to control with the mouse and keyboard of the Primary PC. No manual switching necessary. The keyboard and mouse input is transmitted using any Ethernet, Wireless, Firewire or USB network connection. ...
Проприетарная реализация за денежку (стандартная версия стоит 40 баксов), работает на MS Windows / Mac OS.

Synergy
http://linuxcritic.wordpress.com/2009/09/09/synergy-a-software-kvm-switch-without-the-v/
Есть в репозиториях большинства дистрибутивов (например, вывод поиска в репе Ubuntu 12.04:
apt-cache search synergy
quicksynergy - GUI for easy configuration of Synergy
synergy - Share mouse, keyboard and clipboard over the network
так что все есть).
По ссылке впечатления коллеги от сабжа.

x2x
http://archive09.linux.com/feature/148824.html
Аналогично предыдущей Синергии есть в репозиториях:
apt-cache search x2x
x2vnc - A dual-screen hack - link an MS-Windows and X display
x2x - Link two X displays together, simulating a multiheaded display

Также была открыта для себя мега фича от Intel, но о ней позднее, тут надо разбираться...))

В поисках портативного KVM (KeyboardVideoMouse).

Имея дело с серверами (пусть даже это пылящийся в углу старенький десктоп), зачастую приходится подключаться к ним на месте, что при отсутствии рядом с объектом монитора и клавиатуры может породить небольшую проблему. Надеяться на заказчика / клиента, что серверная у него оборудована всем необходимым, не стоит. Гораздо лучше придерживаться правила "все свое ношу с собой", и если в отношении консольных кабелей, адаптеров, патчкордов, "резиновой" USB клавиатуры, микромышки и портативного DVDшника, это правило не создает особых трудностей, то таскать с собой монитор, мягко говоря неудобно (особенно ЭЛТ))). Все же надежда теплилась и мысль превратить VGA выход на ноуте во вход (VGA grabber) софтовыми средствами преследовала чуть чаще, чем постоянно. Однако долгие поиски в корне обломали эту хрупкую надежду, представив, однако, пару вариантов.
Практически сразу на словосочетания "vga grabber" и "vga to usb kvm" Гугл выдал ссылки на мегаполезняшку, но за хорошие бабки:
http://www.epiphan.com/products/frame-grabbers/kvm2usb/?gclid=CLLoz4mL9rECFYOJDgodrHoAfg
Из описания: ... Epiphan Systems' KVM2USB™ product is a compact pocket sized portable device that conveys the VGA stream from any host computer to a laptop, while emulating the laptop's keyboard and mouse outputs. ...
С разными насадками-переходниками USB - PS/2 и портативными размерами, девайс практически приближается к идеалу, но вот ценничек... 400 баксов без учета доставки и VAT (что-то типа нашего НДСа).
Так что поиск продолжился.
Следующая остановка в гуглении произошла на, к сожалению, помершем проекте:
http://okvm.sourceforge.net/kvmoverip.html
OKVM - опенсорсный проект, подразумевавший создание как программной, так и аппаратной части для KVM'а с управлением по VNC, однако:
... The okvm project team in 2005 developed an open source okvm KVM Development Kit - so engineers could cost effectively roll their own integrated KVM over IP control appliances. ...
... A number of the KVM PCI cards were produced - sponsored by Opengear. However this project did not find traction in the developer community. So kits are no longer available and development in this branch of the project has stopped. Also Opengear now sells a proprietary KVM over IP solution! ...
Вот так, продолжайся этот проект с 2005 года по сие время и кроме PCI карточки, точно был бы и USB'шный девайс. Ну да и земля пухом...
Были мысли таскать с собой IP KVM (от D-Link, TP-Link) с поправкой, что им нужно будет свое питание, но тут опять на взлете срезал ценник - минимум 15000 рублев на price.ru и Яндекс-маркете.
Короче, пока задач с headless серверами не много, пусть оно будет как есть - с матом к инженеграм и админам заказчика, какого этого в серверной нет моника. При увеличении же подобных задач уже будет рентабельнее прикупить Epiphan VGA2USB (время дороже).

Показать скрытые каталоги / файлы (начинаются с "точки") в Gnome (Ubuntu).

В мемориз!
Если при выборе файлов / каталогов через стандартную форму Gnome не отображаются скрытые (с "точкой" в начале), а опций View данная форма не предоставляет, может помочь комбинация клавиш:
Ctrl + h