Отключение IPv6 в Ubuntu: второй способ

Я уже писал про отключение поддержки IPv6. Но, как оказалось, можно сделать проще.

1. sudo nano /etc/default/grub

В строке GRUB_CMDLINE_LINUX="xxxxx" после xxxxxx дописываем параметр для ядра: :

GRUB_CMDLINE_LINUX="xxxxx ipv6.disable=1"

Лично у меня на свежепоставленном сервере эта строка была пустая, поэтому у меня оно выглядит так:

GRUB_CMDLINE_LINUX="ipv6.disable=1"

2. sudo update-grub

3. sudo reboot

Сетевое сканирование на Windows Server 2003

Понадобилось перекинуть каталог для результатов с самбы на 2003 сервер. Ну вот понадобилось, и всё.
И по ряду причин сервер назначения, прописанный в 50+ МФУ менять проблематично. Но это фигня - МФУ и до этого работали с псевдонимом:

1. был сервер srv012
2. он умер и его обязанности легли на srv042, который в DNS получил псевдоним srv012
3. все МФУ радостно сканировали на 042, уверенные, что сканируют на 012
4. после переназначения псевдонима 012 на сервер srv047 почти все МФУ сканировать отказались, причем сканирование на "настоящий" 047 идет "на ура".

Выяснилось, что до 2008, винда не очень любит, когда к ней обращаются не по имени-отчеству, а по прозвищу (не путать с украинским прiзвищем-фамилией). Лекарство описано здесь.
(pluto в примере - сервер 2003 или ему подобный)

===

• connected to server Pluto with the credentials of a user with administrative rights on the server;
• start Registry Editor (Regedt32.exe);
• locate and click the following key in the registry: HKEY_LOCAL_MACHINE\System
  \CurrentControlSet\Services\LanmanServer\Parameters
• on the Edit menu, click Add Value, and then add the following registry value:
  Value name: DisableStrictNameChecking
  Data type: REG_DWORD
  Radix: Decimal
  Value: 1
• quit Registry Editor;
• restart the server Pluto.

===

Отключение IPv6 в Ubuntu

Поднадоело, что по умолчанию новые серверы идут со включенным IPv6, которого нет в нашей локалке.
WebMin утверждает, что


IPv6 запрещен, однако...

Мистика с реестром

Сижу, чешу репу...

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

На одной из машин вылезла мистическая бяка: по непонятным причинам и с неравномерными интервалами начинались странные тормоза на офисо-открываемых документах. Выглядело это примерно так: тыкаем ПКМ по какому-нибудь исполняемому или архивному файлу - моментально открывается контекстное меню. ПКМ по xls, doc(x) и даже чистому txt - возникает какая-то сетевая активность и тормоза на 30-40 секунд, после которых появляется контекстное меню. То же самое при открытии файлов из проводника: при открытии чего-либо офисо-открываемого иногда жуткие тормоза. А иногда - нет.

При этом иногда всё работает идеально.

Проверили всё: полностью прошерстили диски MHDD, протестировали и на всякий случай даже заменили оперативку. Убедились, что проц в порядке и всё такое, в общем - исключили все возможные проблемы с железом.

Сегодня дошли руки поставить wireshark - очень уж смущала эта сетевая активность, причем штатный netstat ничего не показывал.

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

Вопрос: на хрена пациенту искомый? Полез в реестр с поиском по имени искомого. Ну и кто мне сможет объяснить, как это получается?

1. в общей автозагрузке есть ярлык для BGInfo. В нем жестко прописан путь c:\del\bginfo
2. в реестре для этой программы отдельная ветка с shell и opencmd вида \\искомый\с$\del\bginfo

Откуда этот путь взялся в реестре? Я ни фига не понимаю. Еще меньше я понимаю, почему он вообще влиял на доступ ко всем остальным файлам. После исправления сетевого пути на локальный тормоза  исчезли.

Мама, что это было?

(Обходное) решение проблемы с UbuntuOne

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