Хочу взломать свой компьютер через докер.

Запустил в конейнере линукс, подмонтировал туда локальную папку. В неё предварительно скопировал sh. Сделал chmod u+s sh из докера. Вышел из докера - suid бит остался. Запускаю этот sh ожидая, что suid бит его запустит под рутом - но не получается.

vbr@13049:~/test$ ls -la
total 132
drwxr-xr-x 2 vbr vbr   4096 Dec  4 05:51 .
drwxr-xr-x 8 vbr vbr   4096 Dec  4 05:47 ..
-rwsr-xr-x 1 root      root      125560 Dec  4 05:47 sh
vbr@13049:~/test$ stat sh
  File: sh
  Size: 125560    	Blocks: 248        IO Block: 4096   regular file
Device: 801h/2049d	Inode: 3951222     Links: 1
Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-12-04 05:52:33.620839091 +0600
Modify: 2022-12-04 05:47:48.758333113 +0600
Change: 2022-12-04 05:52:24.856885055 +0600
 Birth: 2022-12-04 05:47:48.758333113 +0600
vbr@13049:~/test$ ./sh 
$ id
uid=1001(vbr) gid=1001(vbr) groups=1001(vbr),997(docker)
$ ls /root
ls: cannot open directory '/root': Permission denied

Никаких маунтов с nosuid нет.

Имеется организация в github на бесплатном тарифе.

Имеется несколько закрытых репозиториев.

Хочется иметь reusable workflow, который можно вызывать из этих закрытых репозиториев. Хранить его нужно в публичном репозитории, т.к. на бесплатном тарифе нельзя вызывать reusable workflow из закрытых репозиториев.

К этой организации прикреплены self hosted runners. Они должны использоваться для этого workflow.

В документации написано:

We recommend that you only use self-hosted runners with private repositories. This is because forks of your public repository can potentially run dangerous code on your self-hosted runner machine by creating a pull request that executes the code in a workflow.

В самом публичном репозитории с reusable workflows ничего кроме них самих и какой-нибудь документации ничего не будет.

Хочется понять, как правильно и безопасно это всё организовать.

Есть каталог some/path/secrets/ в нём есть два файла: name.env и name.example.env. Нужно заигнорить первый и разигнорить второй. Таких каталогов и файлов много, нужно универсальное правило.

Логичный вариант (в корне) не сработал

secrets/
!secrets/*.example.*

он всё игнорит в итоге. Пробовал некоторые вариации, не получилось.

Как правильно?

Хочу вычитать входящий запрос по протоколу HTTP 1.0 или 1.1 и послать ответ, в котором будет текст запроса.

Я так понимаю, простой алгоритм вида «читать, пока клиент не закрыл соединение» не сработает, т.к. современные клиенты пытаются в http keepalive и соединение надо закрывать самому со стороны сервера. Но чтобы закрыть соединение, мне нужно вычитать весь запрос.

Выходит, придётся парсить запрос.

Я так понимаю, есть три алгоритма:

transfer-encoding не указан и content-length не указан. Тогда читаем до закрытия соединения.

content-length указан. Тогда читаем указанное число байтов (ну или до закрытия соединения, что будет странно).

указан transfer-encoding и в нём присутствует chunked. Тогда читаем чанки, пока не придёт чанк нулевой длины, что сигнализирует конец запроса.

Пока не понял, что делать, если указан и chunked и content-length, но я прочитаю.

Можно ли считать, что этого хватит для любых разумных и неразумных (но в рамках протокола) запросов?

Ищу легковесную альтернативу Keycloak.

Хотелки:

• Всякие oauth штуки. Тут нужна достаточно продвинутая поддержка - маппинг групп, audience.
• Своя база юзеров с паролями.
• Страница логина. Регистрация не нужна.
• Функционал сброса пароля путём отправки ссылки на почту через SMTP-сервер с авторизацией.
• Sqlite база или что-то подобное.
• Админка для просмотра, добавления и редактирования пользователей.
• Настройки realm-а и прочих oauth штук через конфиги, а не как в keycloak в базе/UI. Чтобы можно было конфиг поменять и запустить с изменённым конфигом, а не тыкаться там по менюшкам.

Нужно что-то легковесное, чтобы стартовало шустро и память не жрало.

В кейклоке не устраивает:

• Долгий старт, несколько минут. Они предлагают собирать свой образ. Это неудобно.
• Жрёт под половину гигабайта на пустой базе.
• Конфиг в базе хранится. Нет удобного способа делать что-то, похожее на gitops. На terraform можно сделать, но это бред какой-то.
• Работает на взрослой базе вроде постгреса. У меня нагрузка смешная, мне это не надо, гемор по поддержке полноценной базы не хочу.

Sudo 1.8.0 through 1.9.12, with the crypt() password backend, contains a plugins/sudoers/auth/passwd.c array-out-of-bounds error that can result in a heap-based buffer over-read. This can be triggered by arbitrary local users with access to Sudo by entering a password of seven characters or fewer. The impact could vary depending on the compiler and processor architecture.

По случаю санкций решил пересесть с айфона на андроид. Зонд это хорошо, но когда у тебя отбирают двагис, это плохо. Купил пиксель 7, вроде говорят, что у гугла самые приятные ощущения.

Про андроид знаю больше как программист, но в повседневной жизни его почти не использовал.

Пока на аосп/ф-дроид переезжать не планирую, но держу этот вариант в уме на всякий случай.

Собственно что вы бы поставили себе на телефон из неочевидных приложений? Может лаунчер какой маст хэв или файловый менеджер. И почему. Что не хватает в стандартном?

У letsencrypt есть неприятная особенность. У него стоит ограничение на 5 сертификатов в неделю для определенного имени. То бишь можно выпустить ровно 5 сертификатов для www.linux.org.ru, к примеру. Если этот лимит превышен, можно запросить сертификат для двух доменов вроде www.linux.org.ru, www1.linux.org.ru и он его успешно выпустит ещё 5 раз и тд.

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

Тут внезапно узнал про сабж. Работает по протоколу ACME, то бишь вообще ничего менять не нужно кроме URL сервера. И вроде как у него вообще нет никаких ограничений на число сертификатов и тд. Конечно бесплатен.

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

Я использую сервер, на котором запущен докер. Локально у меня установлен только клиент-бинарник. Соединение настроено через docker context поверх ssh.

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

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

На всякий случай приведу команды, чтобы стало понятней.

$ s=someserver.com
$ docker run -d --rm --name nginx -p 127.0.0.1:8080:80 nginx
$ ssh $s curl -i --head -sS http://127.0.0.1:8080/
HTTP/1.1 200 OK
$ curl -i --head -sS http://127.0.0.1:8080/
curl: (7) Failed to connect to 127.0.0.1 port 8080 after 10 ms: Connection refused
$ ssh -L 127.0.0.1:8080:127.0.0.1:8080 -N $s
$ curl -i --head -sS http://127.0.0.1:8080/
HTTP/1.1 200 OK

Вот чтобы ssh -L не нужно было запускать, мне хочется.

Надо написать небольшой драйвер. Какие-то отрывочные знания по устройству ОС с университета есть, но драйверы никогда не писал. Драйвер взаимодействует с устройством через общую память. Прям глубоко в тему вникать мне не нужно. Посоветуйте, с чего начать. В идеале книжку, я книжки уважаю.

Нужно генерировать PDF-документ, в котором вставлено сложное векторное изображение.

Сейчас процесс выглядит так: генерируется SVG, растеризуется в PNG, генерируется HTML, в нём вставлено это PNG изображение и результат преобразуется в PDF.

Что не нравится:

1. PDF получается больше, чем, как кажется, должна была бы быть. Ну собственно 99% её размера это эта картинка.

2. PDF в теории это векторный формат, хотелось бы для пущего качества оставлять исходный вектор.

Но общий подход нравится, т.к. каждый этап легко отлаживать, поэтому сам процесс хотелось бы оставить (SVG, HTML).

Собственно в идеале нужен инструмент, которому на вход подаётся HTML в котором какой-то текст, разметка и тд, а также ссылка на SVG. А на выходе получается PDF, в котором SVG преобразован в PS или чего там внутри.

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

Есть утилита rsvg-convert которая умеет конвертировать SVG в PDF, у неё PDF получается хороший, и размер небольшой и вектор остаётся. Но как этот PDF встроить в HTML и потом сгенерировать следующий PDF - не понятно.

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

Сейчас нужно написать небольшой фронт. Проект - типичная опердень, тупо кучка табличек, формочек, CRUD в общем, с псевдо-REST бэкэндом.

Брать планирую реакт, ибо я его знаю. Понятно, что уже с функциями, я примерно в курсе как там что работает в плане базового реакта.

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

Вопрос с тем - что сейчас правильно брать:

1. Для сборки. webpack была жутко муторная ерунда. Слыхал, сейчас esbuild используют, хороший вариант? Я так понял, он typescript компилирует не пойми как, без проверок типов и тд, мне надо с проверками, как это правильно организовать?

2. Для хранения состояния что посоветуете? redux для форм мне тогда показался плохо приспособлен. Да и в целом странная библиотека, вроде концептуально всё просто и понятно, но когда на практике начинаешь использовать, там подтягиваешь 500 библиотек со всякими сагами и внезапно всё становится сложно и непонятно. Не понравилось по итогу. Хотя подозреваю, что сейчас с этим должно быть получше. Гуглится какой-то redux toolkit.

Слыхал, что react-query какая-то волшебная библиотека, которой даже каким-то макаром можно заменить state (а что нельзя - просто в компонентах пускай лежит, без всяких выпендрёжей).

Есть такой сайт: https://cloud.debian.org/images/cloud/bullseye/

Я так понимаю, это официальные образы от Debian для облачных провайдеров.

По указанному URL новый образ появляется примерно раз в месяц.

По адресу https://cloud.debian.org/images/cloud/bullseye/daily/ образы обновляются ежедневно.

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

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

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

Для иллюстрации покажу следующий пример:

#!/bin/sh

set -e

(exit 2)
rv=$?
echo "rv=$rv"

В данном случае мне нужно продолжить выполнение после того, как subshell вернул ошибку. И обработать конкретное значение этой ошибки.

Понятно, что можно сделать set +e в нужном месте. Но может быть есть какой-то более изящный трюк?

Имеется ресурс с параметром count. Например

resource "openstack_compute_instance_v2" "worker" {
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = data.openstack_compute_flavor_v2.worker.name
  user_data   = templatefile("${path.module}/cloud-init/config.yaml.tftpl", { ... })

count больше единицы.

Если я поменяю значение flavor_name или user_data, то все серверы разом будут пересозданы. Это недопустимо. Нужно это делать по одному, мониторя состояние остальных серверов. Не получилось придумать, как это можно сделать адекватно. Пока пришел в голову только один способ:

resource "openstack_compute_instance_v2" "worker" {
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = count.index < var.worker_new_count ? new_worker_name : worker_name;
  user_data   = count.index < var.worker_new_count ? new_user_data : user_data;

продублировать все поля с новыми значениями и меняя переменную var.worker_new_count постепенно пересоздать все ресурсы, начиная с первого. Но будет довольно много дублирования, что кажется не совсем удачным вариантом.

В идеале хотелось бы написать

resource "openstack_compute_instance_v2" "worker" {
  lifecycle {
    ignore_changes = count.index < var.worker_new_count ? [] : [all]
  }
  count       = var.worker_count
  name        = "worker-${count.index + 1}"
  flavor_name = data.openstack_compute_flavor_v2.worker.name
  user_data   = templatefile("${path.module}/cloud-init/config.yaml.tftpl", { ... })

но в этом поле нельзя писать выражения.

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

У провайдера OpenStack. Для виртуальных машин выделяю отдельную подсеть. Для контрольных серверов создаю выделенный балансировщик нагрузки, создаю 3 контрольных сервера, у балансировщика нагрузки фиксированный IP, он распределяет запросы по этим контрольным серверам. Ну и сколько нужно рабочих серверов. Такая конфигурация даёт некоторую доступность в случае небольших аварий или обслуживания серверов, ну насколько это можно сделать в текущих условиях. Сразу скажу, что использую инкапсулированную сеть для pod-ов, без инкапсуляции мне не удалось настроить, bgp-анонсы роутер опенстаковской сети не принимает. То бишь из пода я могу достучаться до сервера, а вот из сервера до пода уже нет.

Собственно стоят следующие задачи, которые нужно решить:

1. Доступ к этому балансировщику нагрузки, чтобы kubectl с локального компьютера использовать.

2. Доступ непосредственно к серверам по ssh. Во-первых, конечно, начальный, чтобы настроить всё, ну и потом может быть нужда.

3. В кластере будут работать ряд внутренних сервисы с единой авторизацией через работающий там же Keycloak, включая авторизацию для kubectl. Внутренние сервисы включают в себя gitlab, grafana, какие-то ещё средства мониторинга и управления вроде kubernetes dashboard. Не все пользователи технически подкованы, чтобы прокидывать туннели через kubectl proxy, поэтому нужен более простой доступ ко всем этим сервисам.

4. Спорный момент. Но всё же. Иногда хочется иметь прямой доступ к сервисам и подам. Например залезть в БД через клиент, просто указав её адрес. Или какой-нибудь задеплоенный под дёрнуть напрямую. Мне сначала это казалось хорошей идеей, но чем больше думаю, тем меньше эта идея мне нравится. Внутренние сервисы часто без авторизации, кому попало дёргать боевые сервисы - наверное всё же этот пункт не нужен.

На текущий момент я вижу и частично опробовал три варианта.

Вариант один - всё публичное. Каждому серверу даём публичный IP помимо внутреннего (ну или одному даём и потом через ssh proxy jump ходим). Балансировщику нагрузки даём публичный IP. В итоге всё торчит нужными портами в интернет. Ну понятно, что фаерволом ненужное закрываем. kubectl просто работает.

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

Вариант два - создаём один бастион-сервер. На нём публичный адрес, ssh и wireguard. Далее на все внутренние серверы ходим либо через proxyjump, либо через wireguard. Обычные пользователи настраивают себе wireguard клиента и одним нажатием подключаются во внутреннюю сеть. А там уже или через колхозный балансировщик нагрузки на haproxy на том же бастионе (не смотрящий наружу), или через провайдерский балансировщик нагрузки получают доступ к внутренним сервисам, выставленным через ingress-ы.

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

Вариант три - создаём в кластере wireguard-сервер. Мне этот вариант сразу понравился больше всего. По сути запускаем pod, в котором запускается wireguard, настрен ip forwarding и masquerade. Имеем доступность - если какие-то проблемы, под перезапустится на другом сервере. Имеем доступ прям к внутренней сети кластера - напрямую можно подключаться хоть к любому поду, хоть к любому сервису. Тут тоже можно сэкономить на балансировщике нагрузки для внутренних сервисов: в кубернетесе любой сервис это балансировщик нагрузки.

Но есть некоторые проблемы. Во-первых если делать не думая, то для этого пода нужен привилегированный режим. А это плохо. Если делать думая, то поду надо выдать capability NET_ADMIN, без неё wireguard настраивать не получается, я точно не знаю, насколько это плохо. А также нужно в кластере добавить unsafe sysctl net.ipv4.ip_forward, чтобы можно было его проставить для пода, тут тоже у меня нет чёткого понимания, насколько это плохо, но в любом случае это лишние телодвижения при создании кластера.

Далее - доступ к сети подов, как уже писал, чуть подумав я пришел к выводу, что не такая уж и хорошая эта идея. Хотя это решается, можно делат nat только на выбранные адреса, а не на все.

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

И самое неприятное на мой взгляд - то, что судя по гайдам никто так не делает. Я собрал свой образ, сам набил все шишки. Это было полезно в любом случае, но я не люблю идти какими-то непроторёнными путями.

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

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

Я изучаю кубернетес и меня восхищает его архитектура. Адски расширяемая и универальная.

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

Но суть в том, что это всё прям идеально ложится на архитектуру REST - есть GET, PUT, PATCH и тд. Что позволяет делать, например, инструмент kubectl работающим универсально со всеми видами ресурсов, причём и с теми, которые добавляют другие разработчики плагинами, для этого код kubectl менять не надо.

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

Суть в том, что всё это настолько универсально, что из этого можно сделать универсальный фреймворк-бэкэнд. Из этих концепций. Причём если сохранить eventual consistency модель, то он будет бесконечно масштабироваться. От разработчика при использовании такого фреймворка будет нужно лишь добавить свои виды ресурсов и написать свои контролеры, которые будут обрабатывать эти ресурсы. На халяву получаем шикарный REST-API, инструменты вроде kubectl, универсально работающие с любыми ресурсами, универсальную и адаптируемую безопасность и, что самое главное, масштабируемость.

И мне интересно - кто-то уже таким занялся? Есть ли такое фреймворки?

У меня есть VPS, на котором нет поддержки custom iso. Хочу попробовать установить OpenBSD. Установил убунту, установил grub-ipxe, загрузил ipxe, настроил сеть.

Сразу скажу, что у меня получилось загрузить OpenBSD двумя способами:

1. Через команду chain https://boot.netboot.xyz/

Далее по менюшкам и тд.

2. Проанализировав скрипты этого сайта я смог частично без него это сделать:

IPXE> initrd https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/cd71.iso
IPXE> chain https://boot.netboot.xyz/memdisk iso raw

Но, как видно, всё равно грузится memdisk с этого сайта который, как я понимаю, дальше каким-то образом передаёт управление на iso.

Хочется попробовать загрузить OpenBSD без этого сайта. Но пока не получилось. Пытался грузить через chain https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/bsd.rd, пытался сделать

imgfetch https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/bsd.rd
chain https://cdn.openbsd.org/pub/OpenBSD/7.1/amd64/pxeboot

но чего в меню pxeboot ввести, чтобы дальше загрузить загруженный в initrd bsd.rd, я не понял. Почему-то маны по этой теме очень куцые. В моём понимании команда imgfetch скачала указанный файл и расположила его в оперативной памяти по некоему фиксированному адресу, и в pxeboot мне нужно передать управление на этот адрес.

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

Есть операторы, которые обещают автоматизацию всего - разворачивают несколько инстансов с репликацией, делают автоматические бэкапы в S3, обновляют версии БД, в общем звучит очень круто.

Есть ли опыт тех, кто обжёгся на сабже и вернулся к обычной инсталляции?

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

Мои критерии:

1. Поближе к центру страны. Времена сейчас какие-то смутные. Хочется держаться подальше от всех границ и потенциально проблемных регионов.

2. Преимущественно русское население. Не критично, но у каждого народа свои обычаи, я с чужим живу с рождения, хочется и со своим пожить. Не воспринимайте как нацпол, пожалуйста.

3. Рядом должен быть большой лес и, желательно, вода (озёра, водохранилища, реки).

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

5. Квартиры должны стоить в районе 70 000 рублей за кв. м. Финансов у меня ограниченное число и переезжать в коммуналку в Москве не хочется. Съём не рассматриваю.

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

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

8. Всё же более-менее «приличное» население в плане достатка. Бывают города с откровенно бедным населением и вытекающими из этого неудобствами быта. Я в таком доме сейчас живу - люди не могут 3000 рублей собрать на замену проводки в доме. Всё очень бедно и держится на последнем издыхании.

Пока по совокупности признаков рассматриваю окрестности Екатеринбурга, Новосибирска, Красноярска. Из них мне больше всего понравился Екатеринбург (кажется он чуть теплей остальных), а в качестве целевого места понравился городок «Заречный» возле Белоярской АЭС. Поэтому помимо прочего буду благодарен за информацию про этот город, в интернете не так много про него пишут.

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