Все записи автора KulMaks

Открытие документов Excel в разных окнах (в разных процессах)

registry, Windows

Иногда приходится решать задачи, которые админскими не назовешь, но пользователи сами решить не могут. Один из таких примеров — открытие документов Excel в разных процессах. По умолчанию, Excel 2010 не позволяет расположить рядом на одном экране 2 открытых документа. Также, невозможно разместить 2 документа одновременно на двух мониторах. Исключение составляют те случаи, когда первый документ мы открыли «как обычно» двойным кликом по нему, затем запустили еще одну копию Excel и открыли второй документ в нем. А между тем, эта фича довольно полезна: если у вас «упадет» excel из-за кривых VBA-скриптов — закроются не все документы, а только упавший. Да и  легче сравнивать и переносить данные из одного документа в другой.

К счастью, решение этой проблемы, по крайней мере для Office 2010 существует. Необходимо всего-то изменить парочку записей в реестре:

1. Открываем regedit (Win+R->regedit->Enter);

2. Переходим в HKEY_CLASSES_ROOT\Excel.Sheet.12\shell\Open\command;

3. Кликаем дважды на ключе (Default) справа и изменяем строку на такую (т.е. в конце строки меняем /dde на /e «%1»:

"C:\Program Files\Microsoft Office\Office14\EXCEL.EXE" /e "%1"

4. Переименовываем ключ command в command2;

5. Переименовываем раздел ddexec в ddexec2.

6. Пользуемся :)

Excel 2010 separate processes

Если захочется открывать так не только xlsx файлы, но и xls — достаточно проделать эти же операции с веткой HKEY_CLASSES_ROOT\Excel.Sheet.8\shell\Open\command

Расчет размера innodb_log_file_size

mysql

С ростом нагрузки на mysql-сервер начинаешь задумываться о том, как еще можно оптимизировать его производительность. Так уж случилось, что на рассматриваемом мной сервере внезапно возросла нагрузка в виде запросов на запись в innodb-таблицы. Любые данные, которые пишутся в innodb, сперва записываются в лог innodb (ib_logfile0 и ib_logfile1) и только потом сбрасываются на диск. Если вдруг скорость записи строк в БД высокая, а файлы лога маленькие — серверу приходится чаще сбрасывать изменения на диск. При этом, мы получаем не последовательный доступ к диску (как при записи одного файла), а случайный — данные пишутся в разные таблицы, в разные БД, которые обычно разбросаны по диску.

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

mysql> pager grep sequence
PAGER set to 'grep sequence'
mysql> show engine innodb status\G select sleep(60); show engine innodb status\G
Log sequence number 84 3836410803
1 row in set (0.06 sec)
1 row in set (1 min 0.00 sec)
Log sequence number 84 3838334638
1 row in set (0.05 sec)

Выполнять эти запросы желательно в момент пиковой нагрузки на сервер
В результате выполнения мы получим два числа. Log sequence number — это число байт, записанных в лог транзакций. Таким образом, мы можем вычислить объем информации, записываемой в минуту в лог:

  3838334638-3836410803=1923835

Т.е. в этом примере в лог записано почти 2 Мб за минуту. По некоторым рекомендациям, размера лога должно быть достаточно для хранения данных максимум за час работы сервера. Т.е. в этом случае размер одного лог-файла стоит сделать 64 Мб. Два лог-файла смогут вместить 60 минут работы сервера.

Блокировка торрентов, скайпа на windows-машинах «дешёвым» методом

Group Policy, Internet, Skype, Torrents, Windows, , , , ,

Торренты в корпоративной сети с одним выходом в интернет — зло. При отсутствии жестоких ограничений на количество коннектов и ограничений скорости, они могут сильно повлиять на работу интернета у остальных сотрудников. В интернете достаточно информации о блокировке торрентов на самом разном железе/софте и самыми разными способами: начиная от подробного анализа пакетов и заканчивая простой блокировкой динамических UDP и TCP портов (>1024). Ни один из способов не дает стопроцентной гарантии, кроме, возможно, использования маршрутизатора Cisco, или аналогов. Проверить их вживую пока не удалось. Все способы, так или иначе, реализуются только на шлюзе. А если посмотреть на проблему с другой стороны?…

После довольно долгого периода наблюдения за сетевым трафиком и приложениями в локальной сети, я понял, что сотрудники в 99% случаев слишком ленивы, чтобы использовать клиенты-торрентокачалки, отличные от utorrent. Именно этот факт позволяет легко отсечь 99% трафика торрентов. По крайней мере, он позволяет вовремя обнаружить и ограничить такой трафик. И реализуется он при помощи групповых политик. Создаем новую групповую политику и открываем в дереве следующий путь: Computer configuration -> Windows Settings-> Policy-based QoS

Policy-based QoS

Кликаем правой кнопкой по Policy-based QoS и выбираем пункт «Create new policy». Вводим имя новой политики и назначаем любое, отличное от нуля, значение DSCP (например, 1):

Policy-based QoS{tip}Лучше использовать «невалидные» с точки зрения DSCP значения, иначе можно попасть на софт, который маркирует свой «правильный» трафик теми же значениеями.{/tip}

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

На следующем экране выбираем «Only applications with this executable name:» и вводим utorrent.exe (или skype.exe, если вы хотите обнаруживать трафик скайпа):

Policy-based QoS

На следующем экране оставляем все по умолчанию:

Policy-based QoS

Далее выбираем протоколы TCP и UDP и завершаем создание правила:

Policy-based QoS

После этого, трафик от процесса utorrent.exe будет маркироваться DSCP флагом «1» и его легко будет обнаружить на любом шлюзе. Действия же, по факту обнаружения, будут зависеть от внутренних политик компании — блокировать или просто наказывать за нарушение полиси.

Форматирование текста в Skype. Новая версия.

Skype

Веселые были времена, когда в скайпе можно было использовать HTML-разметку. При отправке некоторых сообщений можно было вызвать постоянный «вылет» скайпа до очистки истории. Поэтому очень быстро эту возможность отключили: в одной из версий просто HTML-код просто перестал обрабатываться и скайп снова стал серым и унылым.

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

— полужирный шрифт: просто поставьте перед текстом и после него звездочку *. Текст между ними станет полужирным;

— курсив: текст необходимо «заключить» в знаки подчеркивания _тут будет курсив_;

— перечеркнутый: перед текстом и после него необходимо поставить тильду — ~перечеркнутый текст~;

— моноширинный текст: необходимо заключить текст в теги {code}моноширинный текст{code};

— моноширинный текст для всего сообщения: ставим в начале сообщения два восклицательных знака и пробел (!! сообщение);

— предотвратить форматирование текста: просто ставим в начале сообщения два символа @@ и пробел.

Объединение двух сетей с одинаковой адресацией через интернет

LAN, Networks, UNIX,

Объединить две сети через интернет довольно легко. Создаем site-to-site vpn удобным нам способом и пользуемся. А если надо объединить две сети, в которых совпадают диапазоны используемых адресов? Например, две сети с адресацией 192.168.0.0/24. Поначалу может показаться, что идея глупая и это никому не надо. Но есть для этого и практическое применение — обеспечение бесперебойной работы инфраструктуры офиса на время переезда в другое место.

Одним из первых требований, естественно, будет отсутствие совпадающих IP-адресов — в итоге получится одна виртуальная сеть, в которой никто и догадываться не будет, что она разнесена физически на далекие расстояния. Единственным признаком будет увеличение задержек при доступе к «удаленной» части. Впрочем, это требование при сценарии переезда выполнить легко: одинаковых адресов в сети не было и в процессе переезда им неоткуда взяться.

Второе требование — достаточно широкий интернет-канал с низкими задержками. Желательно все это выполнить в пределах одного интернет-провайдера.

И, естественно, третьим требованием будет 2 сервера/компьютера с двумя нормальными сетевыми картами в каждом.

Если все требования выполнены, можно приступать к установке Debian. Именно на этой платформе мы будем реализовывать виртуальный свитч. Описывать установку debian бессмысленно, мануалов в сети предостаточно, да и визард вполне понятен.

После установки debian, ставим пакеты bridge-utils и tinc. Создаем директории /etc/tinc/mynetwork и /etc/tinc/mynetwork/hosts, где mynetwork — имя вашего соединения. В директории /etc/tinc/mynetwork создаем конфигурационный файл tinc.conf и вписываем туда следующие параметры:

Name = segment1
Mode = switch
ConnectTo = segment2

На втором, соответственно:

Name = segment2
Mode = switch
ConnectTo = segment1

В таком режиме, как можно догадаться, tinc будет работать как обычный свитч: пересылаться будут только те пакеты, которые направлены к хостам в другом сегменте. Для этого tinc будет регулярно рассылать ARP-запросы и поддерживать в актуальном состоянии таблицу MAC-адресов. Если же нужна пересылка абсолютно всего трафика — можно воспользоваться режимом «hub», что собственно и соответствует логике работы обычного хаба.

После того, как созданы конфигурационные файлы, надо сгенерировать ключи для установки защищенного соединения. Для этого выполняем команду:

tincd -n mynetwork -K

Эта команда генерирует private key и public key и сохраняет их в указанном месте (по умолчанию, в директории /etc/tinc/mynetwork хранится private key, а в директории /etc/tinc/mynetwork/hosts — public key. Имя публичного ключа совпадает с именем, заданным в tinc.conf параметром Name. Редактируем файл с публичным ключом и вписываем в первой строке (до начала —— BEGIN RSA PUBLIC KEY):

Address = 1.2.3.4

, где 1.2.3.4 — внешний адрес этого хоста. После этого копируем файлы из директории /etc/tinc/mynetwork/hosts с одного хоста на другой.

В директории /etc/tinc/mynetwork создаем скрипт tinc-up с содержимым:

#!/bin/sh

ifconfig $INTERFACE 0.0.0.0
brctl addif bridge $INTERFACE
ifconfig $INTERFACE up

Этот скрипт будет запускаться при старте демона tincd. Для автоматической установки соединения при старте системы, необходимо вписать имя сети (mynetwork) в файл /etc/tinc/nets.boot.

И, наконец, последнее, что необходимо сделать для того, чтобы все работало — создать, собственно, мост и сделать так, чтобы при старте системы он создавался автоматически. Для этого создаем скрипт /etc/tinc/createbridge со следующим содержимым:

#!/bin/sh

brctl addbr bridge
ifconfig bridge 192.168.0.2 netmask 255.255.255.0
ifconfig eth1 0.0.0.0
brctl addif bridge eth1
ifconfig eth1 up

, где 192.168.0.2 — адрес хоста в сети, а eth1 — интерфейс, к которому подключена локальная сеть. Делаем скрипт исполняемым и добавляем в /etc/network/interfaces в параметры интерфейса eth1 строку:

post-up /etc/tinc/createbridge

Перезагружаем оба сервера и проверяем наличие соединения между хостами. Если соединение не установлено — смотрим логи и проверяем наличие интернета. Если не помогло — читаем мануал :)