O Di

У меня на FreeNas самба настраивается так:

[Office]
    path = /mnt/tank/Office
    printable = no
    veto files = /.snapshot/.windows/.mac/.zfs/
    writeable = yes
    browseable = yes
    shadow:snapdir = .zfs/snapshot
    shadow:sort = desc
    shadow:localtime = yes
    shadow:format = auto-%Y%m%d.%H%M-2w
    shadow:snapdirseverywhere = yes
    vfs objects = shadow_copy2 zfs_space zfsacl aio_pthread

Tutorial: Create a simple messaging system on Rails

Меня неожиданно и приятно удивил Dropbox Paper. Там есть Markdown, подсветка кода, to do lists с галочками.
Для черновиков очень подходит: автосохранение, доступ даже с мобильного, не нужно задумываться о коммитах, минималистичный интерфейс как у meduim, возможность поделиться документом и обсудить.

https://paper.dropbox.com/

Ну а потом для финальной публикации, вычитки и поддержки — gitbook или что-то своё.

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

Тоесть, у вас есть проект. Надо реализовать новую фичу шифрования, например. Вы отводите ветку от основной
git checkout -b feature/encryption

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

git clone - выкачать репозиторий
git pull – получение изменений из удаленного репозитория
git checkout - переключиться на ветку
git checkout –b - отведение новой ветки от текущей с переключением на нее
git add – добавление файлов в индекс
git commit –m ‘’ – коммит с комментарием
git push origin - пуш закоммиченных изменений в удаленный репозиторий origin
git branch –d - локальное удаление ветки
git stash save –keep-index + git stash drop – локальное удаление изменений в отслеживаемых файлах

В идеальном мире этим должно заниматься как минимум 2-3 человека, каждый по своей специализации: админ серверный, админ/спец по базам которые вы используете и т.д.

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

Это параметр не тома, а группы.
vgcreate --physicalextentsize

В некоторых случаях параметр можно изменить у уже существующей группы.
vgchange -s

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

Когда я работал в Х банке, мы спускались на лифте в офис разработки, там проходишь рамки, отдаешь мобильники и др. электронику. Выдают офисную рацию для связи.
Каждый комп находится в таком положении, что при желании др. человек не увидит чем вы занимаетесь.
В системниках есть только один usb (и то не везде), который имеет физическую защиту. Служит для банковских ключей. Периферия подключена ps/2.
Вся локальная сеть не имеет доступа во внешний мир.
Код выкладывается на боевую систему через сервер-шлюз. Т.е. данные из рабочей сети выкладываются на шлюз, локальная сеть отрубается а далее уже на продакшен.
Шлюз защищен вероятно хорошо, но этого я уже не знаю.

Так же на столе стоит камера- блок. Когда вы отходите от нее (от компа), система блокируется и просит ввести логин/пароль.

Вот такая система безопасности была на старой работе. Может там и еще что то было, но я этого не знаю.

Примерно на 90% это административный, организационный и юридический вопрос. Техническая часть тут не самое главное.
Правильно организуйте работу. И сделайте так, чтобы вашим сотрудникам было невыгодно "сливать" код на сторону.

1) Перестать ныть. Вселенная вам ничего не должна, но в ней достаточно и работы и денег.
2) Перестаньте искать путь, где не встретите трудностей - такого пути нет. Даже путь сидеть на попе и ничего не делать - несет в себе проблемы. Воспринимайте трудности, как уроки для изменения себя.
3) Не спрашивайте других чем вам следует заниматься в жизни. Это ваша собственная задача и вам ее нужно решить, покопавшись в себе, а не на основе критерия п.2. Для раскопок себя есть соответствующие курсы.

Ряд моментов Вы уже сделали, но я все равно их опишу для полноты списка.

1. Создать отдельного пользователя и хороший пароль на sudo. Не использовать больше root напрямую. Совсем.

2. SSH. Отключаем метод аутентификации по паролю. Если Вам не нужны другие методы, то их тоже можно отключить, оставив только publickey. Отключаем возможность аутентификации root'ом. Включаем использование только 2й версии SSH протокола.

3. Устанавливаем Fail2Ban и настраиваем чтобы после нескольких неуспешных попыток подключения по SSH банило по IP на длительное время. Кол-во попыток и время бана можно тюнить в меру своей паранойи. У меня, например, банит на час после 2х неуспешных попыток.

4. Iptables. Действуем по принципу "запрещено все, что не разрешено". Запрещаем по умолчанию весь INPUT и FORWARD трафик снаружи. Открываем на INPUT'е 22 порт. В дальнейшем открываем порты/forwarding по мере необходимости. Если у нас предполагаются сервисы на соседних серверах нужные только для внутренней коммуникации (Memcached, Redis, и т.д.), то открываем для них порты только для определенных IP. Просто так торчать наружу для всех они не должны.

5. Настраиваем автоматические обновления apt-пакетов. Уровень security. То есть так, чтобы обновления безопасности накатывались автоматически, но при этом не выполнялись обновления со сменой мажорной версии (дабы обезопасить себя от "само сломалось").

6. Устанавливаем ntpd. Серверное время должно быть точным. Также временную зону сервера лучше всего установить в UTC.

7. TLS (не SSL) используем везде где можем. Через Let's Encrypt получаем бесплатные валидные сертификаты. В конфигах веб-серверов, mail-серверов, и других приложений торчащих наружу (в том числе и OpenVPN), запрещаем/убираем использование слабых шифров. Все ключи/параметры генерируем не менее 2048 бит. Самоподписные сертификаты подписываем с помощью SHA-256 (не SHA-1). Diffie-Hellman параметры (dh.pem) под каждый сервис лучше сгенерить отдельно. Проверяем TLS сервисов через Nmap. Минимальный grade должен быть A, не должно быть warning'ов.

8. Правильный менеджмент пользователей/групп. Приложения/сервисы не должны запускаться под root'ом (разве что они действительно этого требуют и иначе никак). Для каждого сервиса создается свой пользователь.

9. Если предполагается upload файлов через PHP (либо другие скриптовые языки), в директории, куда эти файлы загружаются (и которая доступна снаружи), должно быть жестко отключено любое выполнение скриптов/бинарников, что на уровне ОС (x права), что на уровне веб-сервера.

Это была база.
Дальше, в меру своей паранойи можно за'harden'ить сервер ещё следующими моментами:
- SELinux, chroot
- доступ к SSH только с определенных IP (нужно иметь 3-4 VPN-сервера под рукой)

UPD И да, все это помнить/настраивать руками каждый раз может быть запарно. Используйте Ansible и автоматизируйте процесс (там родные и YAML, Jinja2 и Python).

Сам пишу в gitbook. Удобно, что markdown. Можно дополнять плагинчиками.
Вот здесь допустим, можно сохранять в PDF, ePub, Mobi.

Еще были примеры с пошаговым чтением и с сохранением прочитаного, как здесь

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

Я думал все юзают opds каталоги. Не?) типа www.sopds.ru

https://alternativeto.net/

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