Чудесатые интернеты

Решил написать про бредовую ситуацию, с которой я сегодня столкнулся. Связана она была с настройкой виртуалки в Амстердаме у Infobox.

Итак, есть виртуалка, вроде бы всё работает, но при попытке достучаться по самбе, получаю ошибку. Фактически, блокируются 135, 139 и 445-ые порты. Я поплясал с бубном, помучал фаирвол, всё бестолку. В конце-концов, решил проверить доступ с внешней машины. Он был. В полном офигении, я начал копать проблему дальше, и выяснил следующие факты

1. Любой порт кроме этих трёх работает корректно
2. Эти три порта работают корректно из любой доступной мне сети (и интернет-утилит), кроме рабочей
3. Из рабочей сети доступ на данные порты на другие внешние сервисы открыт и работает
4. Никаких запретов на подобное во внутренней сети нет

Т.е., фактически получается, что или провайдер, или хостер рубят эти три порта, именно для нашей сети или для сети хостера. Совершенно безумная ситуация, которая по идее невозможна, а если возможна, то кто-то ведёт себя очень плохо.

Есть, конечно, другой вариант. Он заключатся в том, что я таки сошёл с ума, и мне всё это кажется. С учётом бредовости ситуации, этот вариант допустим.

Вот так, блин, и работаем.

UPD: Оказалось, что это посредник Инфобокса блокирует часть портов, почему-то считая именно эти "небезопасными". Причём, блокирует только с части сетей. Признались они только после длительной переписки с саппортом.

Управление виртуалками для обычных пользователей в Hyper-V 2012 R2

Microsoft иногда очень оригинально относится к безопасности. Перекроет все щели так, что прорваться могут только админы. А потом начинает ныть, что же все сидят под админами. Ну, может быть, потому что кто-то ленится подумать про права?

В своё время, Microsoft выпустила сервер виртуализации Hyper-V, весьма неплохой, хоть и со своими тараканами. И там можно было сделать замечательную вещь: выдать пользователю права на виртуалку, которая крутится на сервере. Т.е. он мог её включать, выключать, дёргать у неё сеть, но при этом, он постоянно к ней подключён, и в тоже время не видит соседей.

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

К сожалению, чтобы раздать эти права, необходимо было произнести несколько могучих заклинаний, сжечь в полнолуние крыло летучей мыши, и попрыгать на левой ноге. Эти действия неплохо описаны в данном блоге. Единственный плюс, что всё-таки появились скрипты для автоматического выкатывания солнца.

Зато, после всех этих мучений, можно было весьма гранулированно раздавать права через AzMan (я, кстати, первый раз его видел, хотя, судя по всему, существовал в системе давно, с XP. Но мы-то знаем, что Microsoft не ищет лёгких путей и всегда есть по крайней мере три несовместимых технологии).

К сожалению, в 2012 R2, эта магия больше не работает. Всё сломано. Мне понадобилось достаточно длительное время, чтобы понять это, т.к. народ умудряется писать статьи о том, что всё таки работает. Не работает. Проверено. С большим скрежетом, я всё-таки нашёл, что можно с этим сделать. А сделать можно только одно: давать пользователю подключаться, к виртуальной машине. Т.е. включить он её не может, но хотя бы может работать с ней. Для того, чтобы как-то добавить права, судя по всему нужна отдельная прослойка, которая со своими жирными правами будет всё делать, уже сам раздавая права. Данной прослойкой может быть System Center Virtual Machine Manager или что-то своё самописное (можно добавить имперсонацию и рулить юзерами, действия тупо выполнять через PowerShell). Но само подключение можно реализовать чуть проще, хотя и не очень очевидно.

Собственно, для возможности подключения пользователя (не админа) к определённой виртуалке надо сделать следующее):

1. Выдать права на виртуалку через PowerShell
   Grant-VMConnectAccess -ComputerName host_name -VMName vm_name -UserName user_name
   Есть ещё команды Get-VMConnectAccess для просмотра прав и Revoke-VMConnectAccess для отбирания
2. В PowerShell выяснить id-нужной нам виртуалки
   Get-VM -ComputerName host_name | select id,name
3. Установить Remote Desktop Connection Manager (стандартный не катит)
4. В нём сделать новую группу, в группу добавить сервер, на вкладке Server Settings поставить VM Console Connect, ввести нужный Id и сохранить всё это дело

После этого можно пользоваться прямым подключением к виртуалке (возможно придётся открыть ещё порт 2179).

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

Ещё одна проблема HttpWebReqest

Я уже писал про грабли HttpWebRequest, но тут нашёл ещё одну забавную, и местами неприятную. Правда наполовину она относится к HttpWebResponse, но классы связаны метровым канатом, так что не принципиально.
Вкратце: работа с куками организована очень оригинально, и не очень логично.

Для удобства распишу по условным пунктам. Для начала диспозиция:

• Сервер возвращает куки в Http-заголовке Set-Cookie
• Если надо установить две куки, сервер передаёт два заголовка (не очень логично, но ок)
• HttpWebResponse имеет пропертю Headers, и по имени заголовка можно получить значение

Тут начинаются проблемы, ибо куки две, а заголовок один. Как вы думаете что вернётся? Не буду томить, скажу, что вернётся в этом методе содержимое двух кук через запятую. Очень, блин удобно. Считаем, что куки у нас разломаны в этом виде.

Но! У Headers можно взять значения через .GetValues(), вернётся честный массив из двух элементов. И вроде бы всё хорошо, и пост можно жакончить, но тут приходит сервер, и выдаёт нам:

Set-Cookie: ABC=123; expires=Fri, 31 Dec 2010 23:59:59 GMT; path=/;

Вы заметили, что между пятницей и 31-ым числом есть запятая? HttpWebResponse тоже заметил, и вместо этой куки честно вернул нам две, обе разломанные. Всё, приехали.

Но обойти это надо, поэтому можно сделать следующие вещи:

• Вручную распарсить значения кук, зная, что запятая, по стандарту, запрещённый символ. Т.е. встретится она может только в expires
• Взять у HttpWebResponse пропертю Cookies, с уже обработанными куками

Вроде второй вариант самый правильный и логичный, за исключением случаев, когда вам хочется посмотреть на изначальные данные от сервера, а не обработанные странным кодом. Но чтобы он работал, надо обязательно, у HttpWebReqest установить пропертю CookieContainer, иначе вам вернётся пустой массив в респонзе.

request.CookieContainer = new CookieContainer()

Немного нелогично (нам ведь только ответные нужны), но в принципе допустимо. И всё из-за весьма странной реализации работы с заголовками.

На этом всё, буду ловить очередные грабли данного класса. 

Немного про починку винды через много букв

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

В качестве примера буду приводить систему, с которой недавно боролся после того, как она сама себе испоганила диск. Точнее не она, заглючил RAID-контроллер и вместо обеспечения целостности запорол кучу файлов (похоже писал данные не в те блоки), потом он, конечно, отправил систему в синий экран, но это было уже потом.

Винда, с трудом но поднялась после всего этого, правда для этого пришлось починить несколько важных для загрузки файлов и собрать монстра из реестра (комбинация из встроенного бекапа в C:\Windows\System32\config\RegBack\ и основного реестра), но в общем-то фатальных проблем не было.
Правда при работе слегка глючила, не давала подключиться удалённо, плюс были ещё мелкие и не очень проблемы (некоторые выявились только спустя несколько месяцев).
Что можно с этим сделать, и как чинить?

Вариант 1. Апгрейд винды на саму себя из установочных файлов

Винда бережно сохраняет все настройки и восстанавливает их в новой системе. Но есть проблема, могут сохраниться ошибочные настройки, а часть данных не перенесётся, причём лучше уж поломанный сервис, который ты знаешь, что надо починить, чем рабочий, у которого потерялась какая-то хитрая настройка, и из-за этого он поведёт себя не так как надо.
Так что этот способ не очень хорош, кроме того требует некоторого даунтайма системы (на установку и настройку сервисов снова). У меня был один такой системный сервис, который очень не хотелось трогать (и да, он разваливается при переустановке, можно поднять его из бекапа, и потом донастроить).
Так что я пробовал другие способы

Вариант 2. sfc /scannow

Способ, который рекомендуют на всех форумах, к сожалению помогает он плохо, т.е. ничего не лечит (ему неоткуда взять корректные файлы при серьёзных повреждениях), но зато создаёт логи в C:\Windows\Logs\CBS\CBS.log, с помощью которых можно узнать повреждённые файлы и физически заменить их с аналогичной системы (тут очень помогает Far, который достаточно вольно относится к отсутствию прав на файлы (т.е. если есть права выдать себе права, но в данный момент их нет, а приказ что-то сделать с файлом есть, фар решит эту проблему самостоятельно). Без фара можно ручками выдавать права на проблемные файлы, меняя владельца с TrustedInstaller на себя и раздавая права (если хочется красоты, следующий запуск sfc /scannow всё починит).
Таким образом я починил большинство проблем и система жила, пока не потребовалось ещё кое-что настроить.
Но для начала

Вариант 3. dism

Утверждается, что свежая винда может себя починить через следующую команду:

DISM.exe /Online /Cleanup-image /Restorehealth

или

DISM.exe /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

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

Вкратце: способ мне не помог, хотя что-то делал и явных ошибок работы не выдавал. Тем не менее, он много каши не просит, поэтому стоит его попробовать.

---

Файлы были починены, но потом неожиданно начал стрелять реестр, причём совершенно непредсказуемо. Я подобных проблем ещё не встречал, гугл тоже даёт подозрительно мало вариантов. Поэтому, тут я расскажу только общие проблемы и возможные пути их решения, ибо если у вас будет подобное, оно будет подобным, а не точно таким.

Итак, на первый взгляд проблемы появились в том, что не ставились апдейты. Изучение ошибок и логов привело к парадоксальному результату: они не ставились, потому что валился Task Scheduler со статусом что-то типа Initialize::UserTable (за точность ошибки не ручаюсь, ибо по памяти). Т.е. совершенно невменяемая ошибка. Были перепробованы все средства, пока не оказалось, что проблема в том, что в управлении пользователями отсутствовали локальные пользователи, а при открытии групп вылезало две ошибки с чтением данных. Т.е. проблема не в этом, а в том что есть именно проблема с пользователями. При этом из консоли (net user, net localgroup) проблем явных не было.

Тут я полез уже в дебри и выяснил следующее:
Вся информация о пользователях хранится в ветке реестра SAM, которая в реестре замаплена на HKEY_LOCAL_MACHINE\SAM. Если вы откроете ветку сейчас, вы ничего там не увидите. Рекомендую добавить себе права.
Там всё внутри устроено оригинально и не так как в остальном реестре. В частности, есть группы пользователей (SAM\Domains\Account\Aliases) и сами локальные пользователи (SAM\Domains\Account\Users). Они идентифицируется неким id, а сопоставление имён и id идёт в отдельном разделе (SAM\Domains\Account\Users\Names\), где в качестве типа указан данный id. Т.е. не значение, а тип. который обычно DWORD, STRING, BINARY. Впрочем, это можно списать на особенности отображения и то, что этот раздел не предназначен для обычных глаз.
У пользователей есть бинарные параметры F и V, а у групп С, которые содержат описание объекта, SIDы, и кто кому принадлежит.
В моём случае, были повреждены разделы C (их тупо не было) у групп администраторов и пользователей, и был один повреждённый пользователь (хотя визуально он был в порядке.
Эти проблемы и вызывали странное поведение в управлении пользователями.
Если хочется тут что-то сделать, вначале делаем бекап, потом играемся как хотим. У нас есть возможность откатиться.
Эмпирическим путём проблемный пользователь был вычислен и уничтожен (удалением ветки реестра), пользователи вернулись в норму. Раздел C, был импортирован с соседнего компьютера и всё ожило (Планировщик, а вместе с ним и апдейты. То ли у них были проблемы с группами, то ли с пользователем). К сожалению, в управлении группами в этих группах появились неизвестные SIDы (неудивительно, с таким-то импортом), которые не удалялись, а также не добавлялись новые пользователи.

Наилучшим решением проблемы я посчитал следующее (очень не хотелось разбираться в бинарной структуре данных записей, не стоит оно того). Например, у нас проблемная группа Administrators. Создаём группу Bdministrators. В эту группу добавляем нужных пользователей (самого администратора, например). Экспортируем из реестра обе группы по отдельности. Переносим бинарные данные из экспортированного файла от Bdministrators в Administrators, и импортируем его назад. Тем самым, у нас появились правильные администраторы (с правильным id), но неправильным именем. Ну, тут открываем в редакторе реестра бинарный редактор и меняем код байтика, отвечающий за B, на A. Всё, у нас правильные администраторы. Лишнюю группу удаляем, чтобы не мешалась. Повторяем тоже самое для других групп.
Результат — всё красиво и работает.

---

На этом пока всё. Я рассказал как чинить файлы, и что можно сделать с реестром. После этого, при желании винду можно восстановить почти из любого состояния, вопрос только целесообразности. А я буду ожидать очередного безумного сюрприза от очередной системы, но также буду надеяться, что он случится когда-нибудь попозже.

Итоги моего года

Выдалось время в этот день написать итоги моего года. В принципе, пишу их для себя и даже не знаю зачем. С учётом того, что тут я готов только писать про профессиональные достижения (есть личные, не связанные с программированием, есть изменения в моём окружении, но это не для этого блога).

Наверное, в будущем, надо писать в блокнотик, потому что всё уже забылось, а что не забылось — не помню в каком году было...   В общем, из того, что вспомнилось:

С помощью использования своих знаний программиста, я выиграл iPad, научился потрошить приложения на андроиде и хачить их для достижения щастья. Матерился на андроид и перевод времени, позанимался алгоритмическими задачами. Из этих задач, самые интересные: архиватор и поиск разницы в файлах.

Архиватор, это офигенная штука! Пока изучал и писал свой, начал разбираться в алгоритмах, их устройстве и теперь уже понимаю с полувзгляда, что можно сделать с набором файлов, как их можно пожать  К сожалению, играться с архиватором гораздо веселее, чем довести его до ума. Поэтому, наигрался вдоволь, но более или менее рабочий вариант представляет собой аццкий говнокод, который надо будет переписывать, ибо видеть его страшно. Впрочем, как допишу, постараюсь написать отдельные посты про это дело, благо я даже делал доклад, и у меня есть слайды и куча желания о чём рассказать. Пример слайда:

С поиском разницы в файлах пришлось изобретать велосипед: ибо это не обычный дифф, а дифф файлов, находящихся на разных компьютерах в разных датацентрах. И обмен информации следует максимально сократить. А потом ещё и подумать — искать разницу, или плюнуть и отдать файл целиком. Т.е. в отличии от теории, надо пользоваться жёсткими эвристиками для оценки требуемых действий. И это интересно.

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

Как-то с профессиональной точки зрения в этом году получилось немного, экзаменов не сдавал, оставил только одну конференцию, для получения новых знаний, и очень сильно ленился доделывать хвосты (количество задач, которые мне хочется сделать просто нереальное, но лень...).

Торжественно обещаю со следующего года всё доделать и продвинуться ещё дальше, залезть в страшные дебри алгоритмов и наделать мегавещей! И как все остальные обещания начать новую жизнь с понедельника, это также пойдёт лесом. Ну, как всегда  

PS: А ещё я научился собирать кубик Рубика за полторы минуты. А потом разучился. И полностью разучился собирать обычные, дешёвые кубики.

Новогоднее RDP

Скоро новый год, а значит выходные, т.е. к серверам лучше не прикасаться, а если прикасаться, то аккуратно. Естественно, Microsoft всех приучило, что самый простой и ненапряжный способ это сделать - RDP (нет, конечно, PowerShell рулит и бибикает, но назвать этот способ простым, как-то язык не поворачивается).

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

Другими словами, при попытке подключения — RDP тупит, а потом идёт отлуп с пространными объяснениями, что всё плохо.
Вы дома, сервер далеко, к нему не подойти и не пнуть ногами. Подключиться — не удаётся.
Практика показывает, что это частое явление при разрывах сети. Т.е. кроме разрыва соединения, ещё появляются такие шикарные эффекты. Причем страдают обычно 8-ые винды (т.е. Windows Server 2012 и 2012 R2)
Что в этом случае можно сделать?

Для начала, конечно же выполнить пункт номер 0 — иметь пути отхода и дырку в фаирволле. Причём делать это по-возможности всегда. Т.е. у вас всегда должно быть как минимум 2 пути подключения к серверу (например через рабочий компьютер и через другой сервер), и желательно на определённые IP иметь хороший список открытых портов для этих дружественных компов. Винда это вам не Linux, тут одним SSH не обойдёшься, особенно когда так тупит RDP!

Вариант первый, банальный и неинтересный:

shutdown /m \\server /r /t 1

Отправляем компьютер в ребут... очевидно и неинтересно. Надо идти другими путями. Другие пути заключаются в том, что надо бы перепустить службу Remote Desktop, которая зовётся TermService.

Тут 2 варианта:

sc \\server restart TermService (оцените синтаксис команды относительно предыдущей)

Или же, с помощью мышки: mmc.exe, добавить остнаску, службы, другой компьютер, перезапуск.

Но, тут как всегда нас ждёт сюрприз... в 90% случаях служба зависнет и не захочет останавливаться. Так что придётся добивать её ногами. Битьё усложняется тем, что она висит в процессе svchost.exe (благо обычно на нужном ничего полезного нет).

Так что

tasklist /s server /svc | findstr TermService (оценили синтаксис?)
taskkill /s server /pid 123456

Ну и запускаем службу. Вроде просто и очевидно, но как всегда лезут нюансы: если у нас плохо с логином и паролем (а мы дома, а не в домене), то получим отказ в доступе. Некоторые команды имеют возможность указать логин с паролем, некоторые используют существующее соединение (net use \\server\c$ - получим замечательное подключение и для управления), некоторые просто отказываются работать.

Можно применить PowerShell, создать сессию на сервер и там всё сделать, но ведь его надо настроить... добавить доверие... в общем если вы не занимаетесь этим специально, работать не будет.

Так что, если всё плохо и ничего не работает, то придётся ползти в сторону Sysinternals, а именно PsTools, и через psexec уже всё делать. Что удивительно, работает это гораздо надёжнее, чем встроенные средства системы. Даже если не разбираться, можно написать

psexec \\server tasklist /svc

И получить тот же результат (да, мне лень изучать другие команды из этого набора ).

Собственно, зачем я это написал? Вроде очевидные вещи. Да в общем-то с двумя простыми целями: в очередной раз поныть на винду, и показать, что если что-то не работает, можно всё-таки обойтись без перезагрузки.

UPD: Спустя время, надо бы добавить ещё пару команд, которые помогут решить подобную проблему. Ибо у Microsoft всё устроено очень сложно, половина команд может работать, а другая половина не работать с дурацкими сообщениями вида (не шутка):
Couldn't access server:

The operation completed successfully.

Соответственно, tasklist /svc в нашём случае можно заменить на

sc queryex TermService

А вот с taskkill посложнее. Может прокатить скрипт на PowerShell

Invoke-Command -ComputerName server -ScriptBlock {Stop-Process -Id 123456 -Force} -Credential DOMAIN\user

Interstellar, впечатления

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

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

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

Дальше будет много спойлеров, так что, если вы ещё не смотрели данный фильм — не рекомендую читать.

Итак, поехали...

Завязка истории следующая: Земле кирдык, все жрут одну кукурузу, но поскольку она у всех сидит в горле, то периодически сжигают посевы. Хотя ладно, буду чуть серьёзнее — постепенно все растения заболевают и дохнут, чтобы другие не болели — посевы периодически сжигают. Все ресурсы человечества брошены не на борьбу с болезней растений, а не выращивание ещё большего их количества. Также, постоянно случаются пылевые бури (слава богу, не радиоактивные), и доблестным американским фермерам, живущих в насквозь дырявых халупах приходится постоянно вытирать песок.
Да, этот мир весьма странен, в нём летают беспилотные самолёты (причём летают 10 лет и больше, на солнечных батареях), комбайны управляются автоматикой, при этом все живут в халупах, ездят на древних пикапах и пользуются унылыми ноутбуками.
У главного героя есть сын, у которого из способностей только возможность стать фермером, и дочь, которая видит призраков. Главный герой одновременно и пилот, и инженер, и мегафизик, который запросто считает баллистические траектории и гравитационные манёвры. Ну а сейчас работает фермером и ремонтирует комбайны.

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

По ходу дела, дочери призрак сообщает банарным кодом некоторые координаты, и главный герой сразу это определяет. Мазафака, запишите координаты двоичным кодом, посмотрите что получится, а потом попробуйте собрать это назад. Ну да ладно. ГГ ведь очень крут! Он бросает всё и ломится по указанным координатам, где застаёт сверхсекретную базу NASA. Где его сразу же берут пилотом на космический корабль, у которого цель найти планеты, пригодные для жизни, чтобы срулить нафиг из этой планеты. Т.е. по факту, получается, что ресурсов у населения планеты Земля дохрена, что они могут отправить толпу людей в другую галактику, лишь бы не жрать кукурузу. Ну и делать всем точно нехрена, потому что все знают, насколько ГГ крут, правда позвонить по телефону ему и пригласить — как-то не догадались.

С планетами всё тоже непросто, есть чёрная дыра в другую галактику, там есть 3 планеты, которые могут быть подходящими для жизни. На двух уже есть люди, которые сообщили, что всё пучком, а третья пока не разобрана. Ну и миссия заключается в том, чтобы посетить всё и выбрать, что получше.

В общем, быстренько все собрались и полетели. ГГ, девушка учёный, бородатый негр и ещё один дядька (тоже учёный). Прилетели они на первую планету, и случайно оказалось, что она находится рядом с чёрной дырой, что на орбите время течёт нормально, а если спуститься, то замедляется. И час, проведённый на планете, равен 7 годам на Земле. Ну а ещё, из иллюминатора не видно, что там происходит. В общем, нашим героям делать нечего, они спускаются на планету, и узнают, что там сплошной океан (и почему в кораблях не делают иллюминаторы?), а предыдущая команда разбилась, и только робот сообщает об успешном приземлении. Твою мышь... Надо было проделать такой путь, чтобы догадаться до того, что догадались герои!

Ладно, минус один участник команды, минус 23 года на Земле, три седых волосинки в бороде у негра, который 23 года тусил на корабле и жрал кукурузу. Никаких психических отклонений нет, на землю отправить ничего не смог (предыдущая команда смогла — эти нет, для пущего сюжета). Герои вернулись на корабль, и стали слушать входящие послания. На Земле люди весьма умные, поэтому из всех вариантов: корабль разбился, корабль засосало в чёрную дыру, команду съели рептилоиды, выбрали самый вероятный: команда просто решила срулить с Земли, ибо в космосе веселее. Ооок...

Ну, наших героев это не остановило, и они полетели на другую планету, где давно живёт Мэтт Деймон и сообщает что всё пучком. Ну, тут всё просто и понятно, Мэтт Деймон всех обманул ради того, чтобы за ним прилетели и его забрали. Продолбав ещё одного члена экипажа и Мэтта Деймона, герои решили полететь к третьей планете.

По пути, ГГ отправился в чёрную дыру, вернулся в прошлое в комнату дочери, начал изображать призрака, а потом азбукой морзе на стрелке часов передал магические формулы чёрной дыры. Извините, но тут я охренел конкретно. По-хорошему, на этом бы и закончить всё, но нужен супер хеппи-энд, поэтому герой вываливается из чёрной дыры, его находят на огромном космическом корабле, который построили с помощью его мегаформул, ну и под конец он ворует истребитель и летит спасать девушку-ученого, которая нашла-таки планету, пригодную для жизни. Куда и зачем в это время летел большой космический корабль, я как-то не уловил. Всё, конец, все счастливы.

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

---

И вот после этого, мне пытаются рассказать, какой это крутой фильм, и какая там глубокая философия. Я вот честно, целый день думал о фильме, пытался что-то выжать, не получилось ничего. Единственное светлое пятно в фильме — боевой нечеловекоподобный робот с чувством юмора, исполняющий роль говорящего R2D2.
Фильм при этом слегка отдаёт Космической Одиссей, но почему-то у Кубрика получилось сделать длинное, затянутое повествование без какого-либо действия очень интересным, тут я не увидел этого.