Ubuntu 15.10 и bluetooth адаптер AR3012

Купил себе ноутбук летом, Lenovo G710. Машинка не без недостатков, самым главным из которых я считаю отсутствие индикаторов обращения к диску и регистровых клавиш, но в целом вполне приличная.
К танцам с бубном для включения встроенного блютуса я был готов. Но в 15.04, которую поставил на этот ноут изначально, вроде бы он заработал искаропки. А может и нет - уже не помню.
А вот под 15.10 - ни в какую.

Спящий режим в ubuntu 15.04, 15.10

История повторяется и повторяется. То, что делал для 13.10, пришлось делать и для 15-ых версий. Почему же до сих пор hibernation не включено по умолчанию???

http://tm-experimental.blogspot.ru/2014/04/1310.html

Немножко о циклах и nslookup

Просто для памяти: массовый nslookup последовательных имен хостов

for a in `seq 56 65`; do nslookup cont30prn0$a|grep "Name:" -A 1; done

С командой seq я уже разбирался ранее, объясню про grep в данной ситуации: nslookup выдает несколько строк информации по каждому хосту, но мне нужны только две - название и адрес искомого хоста, и совершенно не интересны строки с информацией о DNS-сервере и т.п. Поэтому ищу строчку со словом "Name:" и вывожу на экран её и еще одну строку после (-A 1)

Name:    cont30prn056.my.domain
Address: 172.21.123.20
Name:    cont30prn057.my.domain
Address: 172.21.126.157
Name:    cont30prn058.my.domain
Address: 172.21.123.13
Name:    cont30prn059.my.domain
Address: 172.21.123.37
Name:    cont30prn060.my.domain
Address: 172.21.124.203
Name:    cont30prn061.my.domain
Address: 172.21.124.204
Name:    cont30prn062.my.domain
Address: 172.21.123.62
Name:    cont30prn063.my.domain
Address: 172.21.123.63
Name:    cont30prn064.my.domain
Address: 172.21.123.64
Name:    cont30prn065.my.domain
Address: 172.21.123.65

С обратным nslookup несколько проще - вся нужная информация выводится в одной строке, но вот со списком непоследовательных адресов морока.

for a in 123.20 126.157 123.13 123.37 124.203 124.204 123.62 123.63 123.64 123.65; do nslookup 172.21.$a|grep in-addr; done

20.123.21.172.in-addr.arpa    name = cont30prn056.my.domain.
157.126.21.172.in-addr.arpa    name = cont30prn057.my.domain.
13.123.21.172.in-addr.arpa    name = cont30prn058.my.domain.
37.123.21.172.in-addr.arpa    name = cont30prn059.my.domain.
203.124.21.172.in-addr.arpa    name = cont30prn060.my.domain.
204.124.21.172.in-addr.arpa    name = cont30prn061.my.domain.
62.123.21.172.in-addr.arpa    name = cont30prn062.my.domain.
63.123.21.172.in-addr.arpa    name = cont30prn063.my.domain.
64.123.21.172.in-addr.arpa    name = cont30prn064.my.domain.
65.123.21.172.in-addr.arpa    name = cont30prn065.my.domain.

mySQL: использование пробелов и специальных символов в именах столбцов

Год назад я писал о фильтровании результатов работы скрипта. Вынужденно пришлось вернуться к этой теме.

Итак, есть mySQL-база от OCS inventory, есть документы в O/L-офисе, есть в этом же офисе "база данных" (.odb)

Был написан скрипт, выкачивающий кучу данных из базы в нужном мне виде и формате. Год назад написал несколько обёрток для него, которые просто выдергивали из его результатов нужные мне подмножества полей.

Да вот беда! Обёртки прекрасно работают в O/L-офисе, но совершенно не работают, например, в mySQL Workbench.

То есть, конструкция типа select "ip адрес", "имя пользователя" from (результат работы скрипта) прекрасно работает в офисе, но возвращает либо ошибку, либо ерунду в Workbench. При этом столбцы без пробелов возвращаются прекрасно.

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

Вуаля! select `ip адрес`, `имя пользователя` from (результат работы скрипта) работает как минимум в Workbench, как и должно.

VMware ESXi 5.1.0 и зависания

Время от времени старый гипервизор, который вот-вот будет обновлен до ESXi 6, начинает вести себя по-хамски: то у него забивается под завязку виртуальный диск root, то VMwareTools на одной из ВМ теряют возможность обмена по RPC.

Порядок действий:

1. ssh до гипервизора (при необходимости - разрешить ssh с консоли)
2. логин подходящим пользователем с root-правами
3. проверяем место на дисках командой vdf -p
4. /etc/init.d/hp-ams.sh restart
этим убивается /var/log/hpHelper.log, который отъедает кучу места при долгом аптайме

Теперь по проблемным виртуальным машинам.

1. net stop "vmtools"
2. прибиваем, если сам не умрет, процесс vmtoolsd.exe
3. Удаляем или переименовываем плагин "C:\Program Files\VMware\VMware Tools\plugins\vmusr\unity.dll" - ESXi его не использует, но он, плагин, при этом имеет привычку гадить.
4. Создаем на всякий случай "C:\ProgramData\VMware\VMware Tools\tools.conf" с таким содержимым:

# http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2038263
[unity]
Pbrpc.enable=false