Статья удалена

promt: a drawing promo illustration, little robot against the background of large barn locks and keys

Как показала практика, никто не будет нести какую-либо ответственность за утечки ваших персональных данных. Ну, подумаешь, утекла база на несколько миллионов человек у какой-то доставки или такси… Между тем утечек все больше, например тут, тут, или вот тут.

Цифровая гигиена достаточно скучная тема для среднего потребителя контента, но все же привыкли мыть руки после 2020 года, так и в случае с digital-пространством эта рутина должна стать обыденностью.

Многие люди, когда в беседе могут быть упомянуты утечки данных или подтверждения того, что коммерческие корпорации, вроде Google, Apple, Microsoft, etc., используют ваши персональные данные в своих целях, могут сказать, мол, да пускай, мне скрывать нечего. Но, когда упоминаешь, что эти компании знают, что вы едите, какие покупки совершаете чаще всего, по каким сайтам передвигаетесь в течении дня, кто ваш круг общения, какие финансовые транзации совершаете, номера ваших карт, ваши адреса и многие другие чувствительные данные, которые мы тоннами передаём добровольно, меняя личное удобство и комфорт на свои данные — собеседник на секунду округляет глаза, но потом махает рукой, со словами “да и пофиг”, теряя интерес к диалогу.

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

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

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

Возникнет резонный вопрос — ну получил вот злоумышленник мой пароль и что? У меня двухфакторная авторизация по SMS или приложение для генирации кодов, типа Google Authenticator. И это не гарантирует 100% защиты, и вот почему. SMS как второй фактор вообще не лучшая идея, но. А в случае утери доступа к Google-аккаунту вы потеряете еще и доступ к приложению с кодами.

Первый эшелон защиты — один пароль для одного сервиса. Если вы пользуетесь 1-5 сервисами, то пароли еще можно запомнить, но будем реалистами. Тем более лучше всего попросту генерировать и составлять из различных последовательностей свой уникальный пароль, который будет обезличен и у злоумышленника не будет возможность попросту отождествляя ваш аккаунт с вами методом тыка угадать ваш Fluffy19-CaT2022.

Перед нами встаёт задача как-то оперативно управлять нашими паролями, при необходимости изменять их и запоминать, потому что сгенерировав новый пароль вида Asd7_634--sc(324)? вы его помните ровно 0 секунд.

Как вариант, вы заходите начать использовать различные сервисы для хранения ваших паролей, ведь они гарантируют сохранность и приватность ваших данных, например iCloud, Google/Firefox/Any_browser хранилки. Но спешу вас предостеречь, что эти сервисы не могут вам гарантировать на 100% сохранность ваших данных, они не будут вам гарантировать перманентный доступ до ваших паролей в любое время и в любой момент вы можете попросту потерять все свои данные по прихоти владельца сервиса.

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

Первым шагом было бы логично предположить — шифровать пароли, хешировать или еще как-то прятать данные от глаз.

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

Выход из ситуации простой — менеджер паролей Pass и локальный Git-сервер.

Для своих целей мы будем использовать open-source менеджер Pass.

Цитата с сайта:

Управление паролями должно быть простым и соответствовать философии Unix. С pass, каждый пароль живет внутри gpg зашифрованный файл, имя файла которого является названием веб-сайта или ресурса, для которого требуется пароль. Эти зашифрованные файлы могут быть организованы в значимые иерархии папок, скопированы с компьютера на компьютер и, в общем, управляться с помощью стандартных утилит управления файлами командной строки.
passwordstore. org

По сути Pass это bash скрипт, который использует для шифрования GnuPG.

gpg --full-gen-key

Будет преложен алгоритм шифрования:

Please select what kind of key you want: (1) RSA and RSA (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (9) ECC (sign and encrypt) *default* (10) ECC (sign only) (14) Existing key from card

Выбираем RSA, вводим 1.

Далее нам предлагают ввести длину ключа:

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (3072)

Вводим 4096.

Далее нас спрашивают о сроке жизни ключа, я указал бессрочный (0):

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y

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

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

We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy.

Делаем это и получаем свои ключи:

gpg: /home/<username>/.gnupg/trustdb.gpg: trustdb created gpg: directory '/home/<username>/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/home/<username>/.gnupg/openpgp-revocs.d/<cert_name>.rev' public and secret key created and signed. pub rsa4096 2022-01-15 [SC] <cert_name> uid <your_name> <email@mail.com> sub rsa4096 2022-01-15 [E]

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

Показать все публичные и приватные ключи:

gpg -k && gpg -K

Так как gpg использует ассиметричное шифрование, то публичные ключи позволяют нам зашифровать данные, а приватные ключи позволяют нам расшифровать данные.

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

Инициализируем хранилище паролей, указав идентификатор наших ключей:

pass init email@mail.com

Добавим свой первый пароль:

pass insert

Вводим дважды пароль и всё, наш первый пароль сохранен в зашифрованном хранилище.

Его можно посмотреть, набрав:

pass

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

Если набрать просто pass, то мы получим список имен паролей, например:

Password Store ├── notion.so └── openai.com

Вот весь список команд:

--clip -c -- put it on the clipboard cp -- Copy the password edit -- Edit a password with $EDITOR find -- Find password files or directories based on pattern generate -- Generate a new password using pwgen git -- Call git on the password store grep -- Search inside decrypted password files for matching pattern --help -- Output help message help -- Output help message init -- Initialize new password storage insert -- Insert a new password ls -- List passwords mv -- Rename the password rm -- Remove the password show -- Decrypt and print a password version -- Output version information

Мы также можем хранить не только лишь пароль, но и связки login-password и различную другую информацию, для этого добавляем ключ -m

pass insert mysite.com -m

Если я не хочу выводить куда-либо пароль, а просто хочу поместить его в буфер обмена, я сделаю вот так:

pass mysite.com -c # Copied mysite.com to clipboard. Will clear in 45 seconds.

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

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

Публичный ключ, где email@mail. com ваш идентификатор, который вы указывали с именем:

gpg --export -a email@mail.com > pub_email.gpg

Приватный ключ:

gpg --export-secret-key -a email@mail.com > sec_email.gpg

Тут есть 3 пути:

Свой git-сервер в своей локальной сети, доступ к которому будет под VPN (тогда вам не придется орендовать IP у провайдера);
Свой git-сервер где-нибудь у Digital Ocean или Selectel, например;
Приватный репозиторий на gitlab.

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

Попробуем идти от простого к сложному, начнем с приватного репозитория + passforios для телефона.

Первым делом заводим аккаунт, генерируем ssh-ключ, включаем двухфакторную авторизацию и вот это вот всё.

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

Генерируем ssh-ключи:

ssh-keygen -t rsa -b 2048 -C "<your_email@email.com>"

Прокидываем ключи в агент:

eval $(ssh-agent -s) ssh-add ~/.ssh/id_rsa

Копируем публичный ключ:

cat ~/.ssh/id_rsa.pub

Идем вот сюда и вставляем всё в поле Key. Далее в обязательном порядке включаем двухфакторную авторизацию вот тут.

Наш аккаунт готов, создаем приватный репозиторий тут, выбираем тип в поле Visibility Level private.

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

Ознакомились, проворачиваем следующую штуку:

cd ~/.password-store \ && git init --initial-branch=main \ && git remote add origin git@gitlab.com:<your_username>/<repos_name>.git \ && git add . \ && git commit -m "Initial commit" \ && git push -u origin main

Наши зашифрованные пароли лежат в закрытом репозитории. Отлично! Теперь пора синхронизироваться с телефоном. Я покажу это на примере iOS и приложение passforios. Устанавливаем его.

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

Добавляем ключи шифрования в приложение Pass на iOS. Для этого следуем инструкциям на скриншоте:

На последнем скриншоте есть инструкция по экспорту sub-key. Подобное мы делали выше, но там мы экспортировали сами ключи, а здесь будут использоваться саб-ключи. Продублирую этот текст сюда, что бы было проще скопировать и экспортировать.

gpg --export -a <your_key_id> > ~/Documents/subkey.pub gpg --export-secret-subkeys -a <your_key_id> > ~/Documents/subkey

Теперь эти ключи переносим на свой смартфон любым удобным способом (только не через мессенеджеры!). Я, например, перекидывал ключи через свой локальный ftp сервер. Вы можете перекинуть через NAS, если у вас есть, поднять ftp или samba-шару сделать. Короче, перенесите как угодно, только не через внешние сервисы.

Конфигурируем git-репозиторий, для этого следуем инструкции на скриншоте:

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

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

Все готово, мы молодцы! Теперь мы можешь углубиться и синхронизироваться через личный git-сервер, который захостим, например, на Digital Ocean. Принцип настройки самой синхронизации останется таким же, только адрес репозитория будет другим. О том, как поднять свой личный gitlab сервер есть отличная статья от самих Digital Ocean, лучше и понятнее этих ребят я не напишу, так что позволю себе просто сослаться на них.

Внимание! для GitLab заявлены требования в минимум 4Гб оперативной памяти на сервере, так что имейте это ввиду, когда будете поднимать дроплет. Ценник получается слегка кусачий, так что держите эту информацию в голове.

Но мы будем поднимать свой Gitea-сервер, а не Gitlab. Он гораздо менее прожорливый и нам хватит даже самого хилого сервера за 4-6 долларов в месяц, что бы хостить свой большой ресурс с репозиториями.

Упомяну, сли будете пользоваться услугами Digital Ocean не забывайте про мою реферальную ссылку!

DigitalOcean предлагает реферальную программу, сделка будет честной, вам $100-$200 на 2 месяца, мне $25. За это время вы успеете попрактиковаться с облачными тулами, может быть решите разместить там свой проект. При регистрации вас попросят внести $6 на свой депозит, чтобы подтвердить, что вы реальный пользователь. Это цена дроплета на месяц.

Реферальная ссылка: тык!

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

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

После регистрации вам станет доступна панель управления. Настроим безопасный доступ до наших серверов посредством добавления SSH-ключа. Проходим в Settings ⇨ Security ⇨ Add SSH key

Генерируем ssh-ключи

ssh-keygen cat ~/.ssh/id_rsa.pub

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

Копируем весь ключ и вставляем в нужное поле.

Ключ добавлен. Теперь мы можем подключаться к серверу по ssh.

Переходим к созданию непосредственно нашего сервера. В DigitalOcean эти серверы принято называть дроплет (droplet, англ.: капля). Следуем в Droplets ⇨ Create ⇨ Droplets.

Теперь просто следуем моим скриншотам. Нам требуется:

Choose an image: Ubuntu 20.04 (или новее, но LTS)
Choose a plan: Basic (за $5-$6)
Choose a datacenter region: Frankfurt (или ближайший к вам)
Authentication: SSH keys (установлено по умолчанию, если нет — выбираем руками сами)
Choose a hostname: wireguard (можно любое, это ни на что не влияет)
Кликаем Create Droplet

Создастся ваш новый дроплет (может пару секунд придется подождать), копируем его IP-адрес, и идем в терминал (можно использовать терминал прям там, указано зеленой стрелочкой)

Не обращайте внимание на название дроплета, просто у меня там будет крутиться несколько сервисов...<br />

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

ssh root@<SERVER_IP_ADDRESS>

Где вместо <server_IP_address> надо подставить IP-адрес вашего дроплета. Его можно скопировать у дроплета в, кхм… списке дроплетов.

Установим на сервере необходимые инструменты, такие как Docker, docker-compose.

sudo apt update && sudo apt upgrade -y sudo apt-get install \ ca-certificates \ curl \ gnupg sudo mkdir -m 0755 -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg echo \ "deb [arch="$(dpkg --print-architecture)" signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \ "$(. /etc/os-release && echo "$VERSION_CODENAME")" stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin docker-compose sudo apt install snapd certbot

Необязательный шаг: если установится docker-compose ниже 1.27 (проверить можно через docker-compose -v), то надо будет поставить его из исходников, это делается не сложно:

Удалим предыдущую установку

sudo apt-get remove docker-compose sudo rm /usr/local/bin/docker-compose

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

sudo curl -L "https://github.com/docker/compose/releases/download/v2.17.2/docker-compose-linux-x86_64" -o /usr/local/bin/docker-compose sudo chmod +x /usr/local/bin/docker-compose

Проверим версию docker-compose -v, должна быть 2.17.2.

Далее нам нужно создать директорию, где будет храниться файл настройки наших контейнеров docker-compose. yml:

mkdir -p /home/git/gitea

И создаем сам файл настройки:

vim /home/git/gitea/docker-compose.yml

Вставляем туда эту настройку и корректируем под себя:

version: "3" networks: web: driver: bridge db: driver: bridge services: nginx: image: nginx:latest restart: always ports: - 80:80 - 443:443 volumes: - ./nginx.conf:/etc/nginx/nginx.conf - /etc/letsencrypt:/etc/letsencrypt depends_on: - server networks: - web certbot: image: certbot/certbot restart: always volumes: - /etc/letsencrypt:/etc/letsencrypt depends_on: - nginx entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'" server: image: gitea/gitea:1.19.0 container_name: gitea volumes: - ./gitea:/data environment: - USER_UID=1000 - USER_GID=1000 - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=db:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea - ROOT_URL=https://<YOUR_HOST>/ - LFS_START_SERVER=true - LFS_CONTENT_PATH=/data/git/lfs restart: always networks: - web - db volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro depends_on: - db extra_hosts: - "<YOUR_DOMAIN>:<SERVER_IP_ADDRESS>" db: image: postgres:14 restart: always environment: - POSTGRES_USER=gitea - POSTGRES_PASSWORD=gitea - POSTGRES_DB=gitea networks: - db volumes: - ./postgres:/var/lib/postgresql/data

В строку ROOT_URL нужно вписать либо домен, либо IP-адрес сервера.

В настройке extra_hosts указываете домен и IP-адрес сервера.

Чтобы сохраниться в vim и выйти из него, введите :wq.

Давайте разберемся, что тут у нас в конфигурации.

Compose будет запускать 4 контейнера:

Nginx: web-сервер, обратный прокси
Cerbot: ssl сертефикаты от Let’s Encrypt, что бы работал https
Gitea: наш гитхаб, только дома
PostgreSQL: база данных

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

Cerbot генерирует нам сертификаты, которые нужны для HTTPS, без них просто так не заведется. Сертификаты бесплатно выдает Let’s Encrypt. Походите по ссылкам и ознакомьтесь со всем этим.

Gitea и PostgreSQL это наш git-сервис, как gitlab или github, только владельцем будете вы и никто не сможет управлять вашими файлами и репозиториями.

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

sudo certbot certonly --standalone

Cerbot спросит ваш домен и ваш email, все вводим, со всем соглашаемся.

Далее закинем эти сертификаты в папку с Gitea, так как мы в настройке указали, где их искать:

mkdir /home/git/gitea/certs cp /etc/letsencrypt/live/<YOUR_DOMAIN>/* /home/git/gitea/certs

Создадим теперь конфигурацию для Nginx:

vim /home/git/gitea/nginx.conf

И закидываеум туда эту конфигурацию:

worker_processes auto; events { worker_connections 1024; } http { upstream gitea { server gitea:3000; } server { listen 80; listen [::]:80; server_name git.owlpaw.com; location / { return 301 https://$server_name$request_uri; } } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name <YOUR_DOMAIN>; ssl_certificate /etc/letsencrypt/live/git.owlpaw.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/git.owlpaw.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/git.owlpaw.com/chain.pem; location / { proxy_pass http://gitea; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; client_max_body_size 10M; client_body_buffer_size 128k; proxy_connect_timeout 90; proxy_send_timeout 90; proxy_read_timeout 90; proxy_buffer_size 4k; proxy_buffers 4 32k; proxy_busy_buffers_size 64k; proxy_temp_file_write_size 64k; } } }

Сохраняем и выходим: :wq

Теперь все готово для первого старта:

cd /home/git/gitea && docker-compose up -d

Переходим в адресной строке по адресу server_IP>:3000 и производим первичную настройку, выбрав базу данных PostgreSQL и внизу вводите админские данные для учетной записи.

Если вам требуется мягко и правильно положить ваши контейнеры, и не поучать ошибку от Nginx, что порт 433 уже занят, нужно сделать так:

docker-compose down

Если вы все же получаете эту ошибку, проверьте, кто у вас использует этот порт и прибейте этот процесс:

sudo lsof -i :443 sudo kill <process-PID>

Этот вариант сильно проще и его же мы будем использовать при настройке на Orange Pi.

Наш docker-compose. yml будет выглядить следующим образом:

version: "3" networks: gitea: external: false services: server: image: gitea/gitea:1.19.0 container_name: gitea environment: - USER_UID=1000 - USER_GID=1000 - GITEA__database__DB_TYPE=postgres - GITEA__database__HOST=db:5432 - GITEA__database__NAME=gitea - GITEA__database__USER=gitea - GITEA__database__PASSWD=gitea restart: always networks: - gitea volumes: - ./gitea:/data - /etc/timezone:/etc/timezone:ro - /etc/localtime:/etc/localtime:ro ports: - "3000:3000" - "222:22" depends_on: - db db: image: postgres:14 restart: always environment: - POSTGRES_USER=gitea - POSTGRES_PASSWORD=gitea - POSTGRES_DB=gitea networks: - gitea volumes: - ./postgres:/var/lib/postgresql/data

И все, больше никаких манипуляций не требуется.

Запускаем контейнеры и настраиваемся:

docker-compose up -d

Ну а теперь проделываем всё, что делали в пункте Синхронизация через GitLab, только репозиторий создаем теперь в нашем gitea-сервисе и в настройках passforios будем использовать адрес нашего репозитория.

Ух, ну а теперь начинается достаточно дрочная часть, потому что Orange Pi PC Plus, которая стоит 1-2 тысячи рублей, этот тот еще кусок… приключений и веселья.

Многие хотя бы раз слышали про Raspberry Pi, это крутые одноплатные компьютеры с процессорами на arm архитектуре. Это малютки всем хороши, но всегда есть какое-то но, и здесь их больше, чем меньше:

Цена. Эти штуки до недавнего стояли вменяемые 3-6-8 тысяч рублей, за разного толка конфигурацию, но сейчас цены совсем кусачие, это нам не подходит;
Закрытый исходный код. В интернете достаточно примеров бекдоров, которые есть в ПО этих плат.
Температуры у старших моделей. Не знаю, стоит ли в целом выносить это в минусы, так как это в целом проблема мощных одноплатников, но пусть будет.

На рынке существует много альтернатив, но мы остановимся на open-source Orange Pi и для игрулек я себе взял чуть ли не самую дохлую Orange Pi PC Plus на 1Gb RAM и Quad-Core ARM Cortex-A7 1.296GHz. Встала она мне с корпусом, радиаторами, куллером, двумя блоками питания и флешкой 10 класса на 16Gb за 1 тысячу рублей.

Если сравнить её с Raspberry Pi, то, ну, очевидно, она проиграет во всем, а самое главное, что у Raspberry Pi огромное комьюнити и вы легко нагуглите любую проблему с пошаговым гайдом к решению, а вот с OrPi придется знатно так забуриться в гик-сноб-нёрд форумы и попытаться угадать мелодию с двух нот.

Первым делом идём сюда и определяемся с дистрибутивом. Скажу сразу, что Armbian развивается лучше всех, но мне очень лень пробовать что-то другое, так что я возьму Ubuntu Server. К сожалению там ubuntu server 16.04, но, как говориться, это open-source, ешь, что дают. Для нас это не станет проблемой, мы обновимся до 20.04 без особых проблем далее.

Далее просто извлекаем удобным для вас способом образ из архива, например вот так:

tar xvf OrangePi_pc-plus_ubuntu_xenial_server_linux5.3.5_v1.0.tar.gz

Нам нужно подготовить флешку к записи, флешка должна быть отформатирована в FAT, для того, чтобы нам можно было создать загрузочный диск. Это можно сделать через GParted, если вы на Linux-системе или же через HP USB Disk Storage Format Tool если вы на MS Windows.

Далее нам нужно залить операционную систему на подготовленную flash-карту. Для этого можно использовать любое удобное для вас ПО, будь то dd, Unetbootin, Rufus.

Давайте разберем способ через dd, потому что в остальных случаях все интуитивно понятно:

Узнаем имя нашей USB-flash карточки: lsblk или fdisk -l

Ищем нашу флешку по объему, моя на 16Gb, и имя у него /dev/sdb, ваша также будет /dev/sdb или /dev/sdc.

Далее нам необходимо размонтировать том и отформатировать флешку:

umount /dev/sdb* && mkfs.vfat /dev/sdb –I

Теперь заливаем образ на флешку, образ лежит ~/Downloads/OrPi_ubuntu_1604.iso:

dd if=~/Downloads/OrPi_ubuntu_1604.iso of=/dev/sdb

Это займет какое-то время, после окончания процесса ваша флешка готова к использованию в Orange Pi.

Мы залили на флешку образ, вставили карточку в плату, подключили питание, клавиатуру и монитор, что дальше?

Дальше стоит произвести некоторые манипуляции, после которых можно будет отключить от платы монитор и клавиатуру и закинуть её куда-нибудь подальше в пыльный угол, но до этого войдем в систему: login — root, password — orangepi.

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

Забегая вперед вы 100% столкнетесь с двумя распространенными проблемами:

Недоступность всего объема памяти флеш-карты для /;
Маленький объем в /boot.

Про первый пункт даже в самой документации есть, не знаю, почему это не исправили спустя столько лет, штош… open-source moment.

Расширяем доступный объем для файловой системы: для нас учтивые разработчики положили скрипт, который нам нужно просто запустить из под root.

/etc/init.d/resize2fs start

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

Ооо, я с этим просидел в поисковике не один час, а решение было очевидное. Суть проблемы:

Есть раздел /boot, у которого выделено 10-15Mb, это очень мало и мы не сможем обновиться;
Раздел /boot отформатирован как FAT16, а GParted использует внешний модуль из другой библиотеки для форматирования и там (проблема существует с 16 года) до сих пор не добавлена возможность расширить или как-то работать с разделами < 256Mb. Open-souce moment.

Мы выйдем из положения просто:

Копируем все из папки /boot куда-нибудь себе на компьютер;
Форматируем раздел в ext4;
Расширяем его до 512Mb, предварительно откусив это место от раздела /;
Форматируем расширенный раздел в FAT16;
Заливаем обратно файлы в /boot, которые мы копировали к себе в п. 1.

Отлично! Мы только что починили две проблемы, которые не дали бы нам обновляться в будущем, но осталось еще несколько…

У нашей игрушки есть самая бесячая проблема -- включается скринсейвер и плата будто бы засыпает. Такие манипуляции ни к чему не приведут:

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

Все это из-за того, что из коробки у нас устаноновлены иксы (x11-core). Удаляем все это:

sudo apt-get remove xserver-xorg-core && apt-get remove --purge x11-common && apt-get autoremove && reboot

Минус еще одна проблема. Теперь можно обновляться до 20.04: sudo do-release-upgrade. На все соглашаемся, все подтверждаем.

После всех действий можно откидывать все лишние шнурки от платы и подключаться к ней через ssh, выясняем IP-адрес сервера в админке вашего роутера или прям на месте: ifconfig | grep 192.168*

Вот тут я уже рассказывал, как нам можно поднять VPN, через который мы
соберем устройства в приватной сети. Нам останется только добавить новый Peer для нашего сервера и настроить сам сервер.

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

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

Дальше переходим на наш OrPi сервер и там устанавливаем wireguard-tools:

sudo apt install -y wireguard-tools

Создаем файл конфигурации /etc/wireguard/wg0.conf и вставляем в него это (поменяв ip-внешнего сервера и ключи на свои):

[Interface] PrivateKey = <YOUT_PRIVATE_KEY> Address = 10.0.0.10/32 DNS = 8.8.8.8 [Peer] PublicKey = <SERVER-PUBLICKEY> Endpoint = <SERVER-IP>:51820 AllowedIPs = 0.0.0.0/0 PersistentKeepalive = 20

Все готово, подключиться к VPN: wg-quick up wg0, отключиться от VPN: wg-quick down wg0.

Добавим в cron задачу, что бы после рестарта включался VPN crontab -e и добавляем в конец файла следующее:

@reboot sleep 60 && wg-quick up wg0 >>/tmp/cron_log 2>&1

Сохраняемся. Вы великолепны! Теперь вы можете подключиться к своему серверу не из локальной сети.

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

Скачиваем бинарник:

mkdir /var/lib/gitea/ \ && cd /var/lib/gitea/ \ && wget -O gitea https://dl.gitea.com/gitea/1.19.0/gitea-1.19.0-linux-arm-6 \ && chmod +x gitea

Создадим все нужные директории:

mkdir -p /var/lib/gitea/{custom,data,log} chown -R git:git /var/lib/gitea/ \ && chmod -R 750 /var/lib/gitea/ \ && mkdir /etc/gitea \ && chown root:git /etc/gitea \ && chmod 770 /etc/gitea

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

adduser \ --system \ --shell /bin/bash \ --gecos 'Git Version Control' \ --group \ --disabled-password \ --home /home/git \ git

Скопируем бинарник в глобальную папку:

cp gitea /usr/local/bin/gitea

Теперь создадим файл службы:

vim /etc/systemd/system/gitea.service

И закинем туда конфигурацию:

[Unit] Description=Gitea (Git with a cup of tea) After=syslog.target After=network.target ### # Don't forget to add the database service dependencies ### # #Wants=mysql.service #After=mysql.service # #Wants=mariadb.service #After=mariadb.service # #Wants=postgresql.service #After=postgresql.service # #Wants=memcached.service #After=memcached.service # #Wants=redis.service #After=redis.service # ### # If using socket activation for main http/s ### # #After=gitea.main.socket #Requires=gitea.main.socket # ### # (You can also provide gitea an http fallback and/or ssh socket too) # # An example of /etc/systemd/system/gitea.main.socket ### ## ## [Unit] ## Description=Gitea Web Socket ## PartOf=gitea.service ## ## [Socket] ## Service=gitea.service ## ListenStream=<some_port> ## NoDelay=true ## ## [Install] ## WantedBy=sockets.target ## ### [Service] # Uncomment the next line if you have repos with lots of files and get a HTTP 500 error because of that # LimitNOFILE=524288:524288 RestartSec=2s Type=simple User=git Group=git WorkingDirectory=/var/lib/gitea/ # If using Unix socket: tells systemd to create the /run/gitea folder, which will contain the gitea.sock file # (manually creating /run/gitea doesn't work, because it would not persist across reboots) #RuntimeDirectory=gitea ExecStart=/usr/local/bin/gitea web --config /etc/gitea/app.ini Restart=always Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea # If you install Git to directory prefix other than default PATH (which happens # for example if you install other versions of Git side-to-side with # distribution version), uncomment below line and add that prefix to PATH # Don't forget to place git-lfs binary on the PATH below if you want to enable # Git LFS support #Environment=PATH=/path/to/git/bin:/bin:/sbin:/usr/bin:/usr/sbin # If you want to bind Gitea to a port below 1024, uncomment # the two values below, or use socket activation to pass Gitea its ports as above ### #CapabilityBoundingSet=CAP_NET_BIND_SERVICE #AmbientCapabilities=CAP_NET_BIND_SERVICE ### # In some cases, when using CapabilityBoundingSet and AmbientCapabilities option, you may want to # set the following value to false to allow capabilities to be applied on gitea process. The following # value if set to true sandboxes gitea service and prevent any processes from running with privileges # in the host user namespace. ### #PrivateUsers=false ### [Install] WantedBy=multi-user.target

Включаем нашу службу:

sudo systemctl enable gitea && sudo systemctl start gitea

Всё! Теперь идем по вашему локальному (192.168.*. *:3000) или внешнему адресу VPN (10.0.0.10:3000), производим первичную настройку (в этом варианте я выбрал в качестве базы данных SqlLite) и все. Вы подняли свой git-сервис на своей локальной машине, который доступен только из под вашего VPN и локальной сети маршрутизатора.

Оставьте, пожалуйста, обратную связь в комментариях, это мой первый пост на DTF. Задавайте свои вопросы и указывайте на мои ошибки, давайте учиться вместе!

Спасибо вам за внимание, увидимся в следующих заметках!

Вода по теме безопасности

Как мои аккаунты могут быть взломаны

Почему важно иметь разные пароли

Как будем хранить пароли

Pass — лучший менеджер паролей

Создаем ключи шифрования

Учимся пользоваться Pass

Перенос паролей и ключей на другие устройства

Экспорт и импорт ключей

Синхронизация с мобильными устройствами

Синхронизация через GitLab

Свой Git-сервер на DigitalOcean

Настройки безопасности на DigitalOcean

Создаем дроплет и производим базовую натсройку

Если мы хотим использовать свой домен с https

Если мы хотим поднять просто git-сервис без свистоплясок и домена

Экста-уровень, свой git-сервер на Orange Pi под VPN

Подготавливаем flash-карту

Первый старт

Исправляем проблемы с доступной памятью flash-карты

Расширяем объем /boot

Исправляем проблему с уходом в сон

Показываем сервер наружу через VPN

Устанавливаем Gitea