21 окт. 2015 г.

VirtualBox 4.3 VERR_SYMBOL_NOT_FOUND

После одного из обновлений старенького Virtualbox на стареньком же ноуте еще с windows xp словилась при запуске виртуальной машины проблема вида: 
VERR_SYMBOL_NOT_FOUND
Из других сообщений было понятно, что не нравится виртуалбоксу USB2.0 контроллер в виртуалке. Обновления ExtensionPack, отключения контроллера в свойствах виртуалки проблему не решали.
Также не помогла переустановка самого VBox и отключение антивируса. Решение пришло внезапно в виде такой мантры (да-да, вторая мантра за день!):
netsh int ip reset reset.log
Вдохновение описано в последнем комментарии тут. Какая связь между сбросом ip стека винды и странным поведением VBox, неясно, однако указанное действие поставило точку в полудневных попытках реанимировать систему.

Windows svchost.exe list of services

tasklist /svc /fi "imagename eq svchost.exe"
Вот эту мантру нужно ввести, чтобы понять, что стоит за каждым из svchost.exe.

14 окт. 2015 г.

Adobe Reader filename too long.

У многих сотрудников довольно развесистая структура папок и длинные называния документов. В итоге это приводит к ограничению в 255 символов на длину пути. Однако если для ранних версий ОС это было фатальным ограничением, то та же windows 7 способно без особого вреда для себя и для файла это исключение корректно обрабатывать. Однако ряд приложений, например, Adobe Reader, при попытке открыть файл по такому длинному пути, по умолчанию выдает ошибку отказа в доступе (что частенько путает пользователя и администратора).
Лечится это довольно просто, в настройках приложения следует отключить "защищенный режим": 
Редактирование – Установки – Категории: Защита (повышенный уровень) – Включить защищенный режим при запуске (снять галку).
После перезапуска самого приложения проблема устраняется. 

7 окт. 2015 г.

retrieve printer list: NT_STATUS_UNSUCCESSFUL

Избавляемся от надоедливых сообщений в логе самбы:
smbd[5895]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsUnable to connect to CUPS server localhost:631 - Неправильный дескриптор файла
smbd[5895]: STATUS=daemon 'smbd' finished starting up and ready to serve connectionsfailed to retrieve printer list: NT_STATUS_UNSUCCESSFUL
В секции [global] файла smb.conf нужно добавить:
##noprinters
        load printers = no
        printing = bsd
        printcap name = /dev/null
        disable spoolss = yes
И перезапустить samba4.

samba4 secrets.keytab regeneration (fix KVNO mismatch error)

Запишу, чтобы не затерялось.
Внезапно перестали вводиться компьютеры в домен. Подозреваю, все остальное, завязанное на контроллере домена и кейтабах, тоже бы отпало, если бы работало. Логи samba4 показали ошибку:
GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find DC0$@EXAMPLE.ORG(kvno 7) in keytab FILE:/var/lib/samba/private/secrets.keytab (arcfour-hmac-md5)
Содержимое "родного" кейтаба, создаваемого при развертывании домена:
root@dc0:/var/lib/samba/private# klist -ke secrets.keytab
Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HOST/dc0@EXAMPLE.ORG (des-cbc-crc)
   1 HOST/dc0.example.org@EXAMPLE.ORG (des-cbc-crc)
   1 DC0$@EXAMPLE.ORG (des-cbc-crc)
   1 HOST/dc0@EXAMPLE.ORG (des-cbc-md5)
   1 HOST/dc0.example.org@EXAMPLE.ORG (des-cbc-md5)
   1 DC0$@EXAMPLE.ORG (des-cbc-md5)
   1 HOST/dc0@EXAMPLE.ORG (arcfour-hmac)
   1 HOST/dc0.example.org@EXAMPLE.ORG (arcfour-hmac)
   1 DC0$@EXAMPLE.ORG (arcfour-hmac)
   1 HOST/dc0@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 HOST/dc0.example.org@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 DC0$@EXAMPLE.ORG (aes128-cts-hmac-sha1-96)
   1 HOST/dc0@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
   1 HOST/dc0.example.org@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
   1 DC0$@EXAMPLE.ORG (aes256-cts-hmac-sha1-96)
Строчка с DC0$@EXAMPLE.ORG в кейтабе есть, однако KVNO отличается, отсюда и ошибка. Почему такое не случалось раньше (или случалось, но не приводило к проблеме) и как этого избежать, неведомо. В интернетах нашлись кивания на то, что такое поведение Active Directory в принципе нормально, есть даже RFC 4120, где я, правда, нужной информации не почерпнул. 
Вообще, вроде как, изменение kvno вызывать проблем с авторизацией не должно, тем более что Active Directory его значение игнорирует (исключая случай работы с RODC, но это мимо кассы). Но вот так получилось. 
Как это можно симптоматически порешать? Регенерацией кейтабов, где имеет место быть разночтение KVNO.

В примерах команды идут в одну строчку:
samba-tool domain exportkeytab  /root/1.keytab --principal=HOST/dc0.example.org@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/1.keytab --principal=HOST/dc0@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/1.keytab --principal='DC0$@EXAMPLE.ORG'
samba-tool domain exportkeytab  /root/2.keytab --principal=DNS/dc0.example.org@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/2.keytab --principal=DNS/dc0@EXAMPLE.ORG
samba-tool domain exportkeytab  /root/2.keytab --principal=dns-dc0@EXAMPLE.ORG
Дальше проверим правильность сгенерерированных файлов и заменим старые кейтабы новыми:
cd /var/lib/samba/private/
klist -ke /root/1.keytab
klist -ke secrets.keytab
mv secrets.keytab secrets.keytab.bak
cp /root/1.keytab secrets.keytab
systemctl restart samba-ad-dc.service
klist -ke /root/2.keytab
klist -ke dns.keytab
mv dns.keytab dns.keytab.bak
cp /root/2.keytab dns.keytab
chown bind:bind dns.keytab
systemctl restart bind9.service
Аналогично следует поступить и с другими службами, если они оказались затронуты проблемой.