Hacker News Digest

Краткое руководство

Цель:
Сервер Ubuntu засыпает при простое и просыпается по запросу любого устройства в сети (SSH, Time Machine и т.д.).

Что нужно:

• Сервер с поддержкой Wake-on-LAN по unicast.
• Постоянно включённый маломощный Linux-компьютер (например, Raspberry Pi).

---

На сервере

1. Включить Wake-on-LAN (unicast):

sudo ethtool -s eno1 wol ug
sudo tee /etc/networkd-dispatcher/configuring.d/wol <<'EOF'
#!/usr/bin/env bash
ethtool -s eno1 wol ug || true
EOF
sudo chmod 755 /etc/networkd-dispatcher/configuring.d/wol

1. Автоматический сон по cron (каждые 10 мин):

cat >/home/ubuntu/auto-sleep.sh <<'EOF'
#!/bin/bash
users=$(who | wc -l)
afp=$(lsof -i:548 | wc -l)
[[ $users -eq 0 && $afp -lt 3 ]] && systemctl suspend
EOF
chmod +x /home/ubuntu/auto-sleep.sh
(crontab -l 2>/dev/null; echo "*/10 * * * * /home/ubuntu/auto-sleep.sh | logger -t autosuspend") | crontab -

1. Отключить IPv6 (ARP не работает с IPv6):

sudo sed -i 's/GRUB_CMDLINE_LINUX=""/GRUB_CMDLINE_LINUX="ipv6.disable=1"/' /etc/default/grub
sudo update-grub && sudo reboot

1. Остановить Netatalk перед сном (по желанию):

sudo tee /etc/systemd/system/netatalk-sleep.service <<'EOF'
[Unit]
Description=Netatalk sleep hook
Before=sleep.target
[Service]
Type=oneshot
ExecStart=-/usr/bin/systemctl stop netatalk
ExecStop=-/usr/bin/systemctl start netatalk
[Install]
WantedBy=sleep.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable netatalk-sleep.service

---

На Raspberry Pi

1. Установить ARP Stand-in
   Отвечает на ARP-запросы за спящий сервер.
   https://github.com/danielpgross/arp_standin

2. Опубликовать mDNS-записи (по желанию):

sudo apt install avahi-daemon
sudo tee /etc/systemd/system/avahi-publish.service <<'EOF'
[Unit]
Description=Publish custom Avahi records
After=network.target avahi-daemon.service
[Service]
ExecStart=/usr/bin/avahi-publish -s homeserver _afpovertcp._tcp 548 -H homeserver.local
[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload && sudo systemctl enable --now avahi-publish.service

---

Ограничения:

• Сетевая карта сервера должна поддерживать Wake-on-LAN по unicast.
• Лишние пакеты могут случайно разбудить сервер.

• Автор статьи описал сложную схему «спящий сервер + Raspberry Pi-прокси», чтобы экономить электричество и «прозрачно» будить машину по любому сетевому запросу.
• Комментаторы спорят: стоит ли так заморачиваться, если можно просто посылать WoL-пакет, ставить BIOS-таймер или вообще купить сервер, который без нагрузки жрёт 7-15 Вт.
• Некоторые делятся альтернативами: «умные» розетки, механические таймеры, PiKVM, USB-гаджеты для нажатия кнопки питания, RTC-будильник, подвешенные DNS-прокси.
• Часть участников считает игру свеч: «RPi стоит дороже, чем сэкономишь на электричестве»; другие приводят счётчики: 10 Вт круглый год ≈ 25-65 $ в Европе, а у кого-то сервер жрёт 130-160 Вт.
• Итог: если нужна абсолютная прозрачность и нельзя трогать клиентов — решение полезно; в остальных случаях достаточно WoL, BIOS-таймера или просто маломощного железа.

git-annex — управляет большими файлами в git, не храня их содержимое. Поддерживает синхронизацию, резервное копирование, шифрование и работу офлайн.

Для любителей командной строки — полный функционал; для остальных — git-annex assistant превращает всё в простую синхронизацию папок.

Быстрый старт

• установка
• обзор
• советы

Ключевые темы

• как работает
• специальные remotes
• сценарии
• предпочтения содержимого

Примеры

Архиватор Боб хранит данные на множестве отключённых дисков. git-annex показывает, где лежит нужный файл, и позволяет безопасно переупорядочивать дерево. Ночью cron-команды добавляют новое и отслеживают дубликаты.

Кочевница Алиса синхронизирует ноутбук, USB-диск, сервер и облако как git-удалённые репозитории. В самолёте или кафе она выбирает, что скачать, что удалить, а при подключении всё автоматически сливается обратно.

• git-annex отлично подходит для персонального управления большими файлами на множестве носителей, включая офлайн-диски, и гарантирует контроль целостности.
• Пользователи жалуются на сложность освоения, «тяжёлый» Haskell-стек зависимостей и проблемы с плагинами облачных провайдеров.
• В много-юзерных репозиториях «магические» ветви git-annex плохо масштабируются; для коллаборации чаще выбирают Git-LFS.
• Крупные репо (десятки ТБ и сотни тысяч файлов) замедляются до минут ожидания на каждую операцию, особенно при дефолтных «параноидальных» проверках.
• Git-annex и LFS решают разные задачи: первый — распределённое резервное хранение, второй — версионирование больших файлов в dev-репозиториях.