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

Тобто, додавання користувача в систему

суттєво засмічує систему зайвими бібліотеками

В решті решт це може вплинути на стабільність

це яким чином? не розумію.

Для разових задач — так, віртуалка це варіант. Для постійної роботи — не дуже раціонально.

Якщо vpn client такий що жити не може без зміни дефолту — можна спробувати просто додати 0/1 128/1 на default gateway.

можна про це детальніше?

і невпевнений чи автоматизація для згаданих sysv/openrc легко переноситься на systemd який зараз у більшості мейнстрім лінукс

є така підозра і у мене. systemd занадто складний, щоб зробити щось просте на ньому. Це той варіант коли enterprise developrs добрались і до Linux

Якщо немає необхідності одночасної роботи в кількох середовищах, то запропоноване рішення вироджується в щось типу
```
useradd yetanotheruser
```
Логінитесь почергово в потрібний акаунт і працюєте.
Як результат: завжди використовуєте всі наявні ресурси машини і немає необхідності обслуговувати кожну віртуалку. У вас одна ОС. Один раз оновлюємось, один раз щось налаштовуємо, фіксимо, і т.п.

Отакої. Віртуалки в даній статі не став приводити як приклад, оскільки думав, що їх недоліки для описаної задачі очевидні. Серед них:
1. Неможливість гнучкого і раціонального використання ресурсів. Для віртуалки потрібно «відрізати» ресурси кожен раз. Як результат: запустити 2-3 віртуалки одночасно з повноцінним робочим енвом дуже складно. Рано чи пізно опиняєшся в ситуації «і сам не гам і іншим не дам».
2. Кожну віртуалку потрібно обслуговувати окремо. Накатувати апдейти, інсталювати новий софт. В деяких випадках, якщо софт вимагає ліцензію, поставити його на кілька віртуалок з одним ключем може не вийти.
Для разових задач — згоден. Віртуалка це варіант. Хоча в лінуксі докер може бути ще простішим і швидшим варіантом.
Тут же я розглядав варіант повноцінного робочого середовища на постійній основі і з необхідністю одночасної роботи в кількох середовищах

при роботі з kind ще буде корисним монтувати директорій containerd на свою хост машину.
Тоді, не доведеться скачувати докер іміджі кожного разу коли ви рестартуєте кластер, що значно скорочує час розгортання. Щось типу такого:

....
  extraMounts:
  - containerPath: /var/lib/containerd
    hostPath: /home/user/.kind/cache/containerd
....

  pullPolicy: "IfNotPresent"

Якось робив дуже схожу річ з метою мати кілька користувачів в системі залогінених одночасно і щоб кожен з них мав свій нетворк. Ну тобто щоб коли один користувач запускає ВПН це не афектило інших. Дивно, але готового рішення на той момент не знайшов, хоча юзкейс ніби доволі тривіальний. В моєму випадку я звісно не робив chroot, натомість додавав ще mount namespace в якому ізолював /etc/resolv.conf. Загалом все працює, більше того, в створеному руками неймспейсі я запускав докер в якому запускав k8s через kind. Ну тобто ця ізоляція може бути вкладеною, і не один раз. Дякую за статтю.

opendatabot насмішив.
Зайшов на ту сторінку щоб дізнатись про альтернативи телеграму, а там таке: «Отримуйте аналітику від Опендатабот в Телеграм каналі». Ну і зрозуміло, що його в списку нема. Бо, мабуть «єта ж другоє». Ну і аналогічне питання до Асоціації: то що з телеграмом робити будемо?

Нагадало мені кінець 90х коли всі казали «ну нарешті настали ті часи коли є нормальні річ інтерфейси і складні задачі можна робити швидко і не думаючи. Прощавай страшний чорний екран. Дякую Майкрософт». І от пройшло 20 років і тепер якщо тобі потрібно працювати з Майкрософт клаудом, то перше що треба встановити це azure-cli.
Якось довелось працювати з американцем старшого покоління, ну такий собі американський айтішник часів холодної війни. То він був фанат аліасів. Якось він поділився своїм файлом аліасів і в ньому було майже 2 тисячі аліасів. Я спитав — Кен, ти правда всім цим користуєшся? (він його називав kenix). А він — «ну там є деякі старі речі, але десь половину використовую постійно». Я подумав що це жарт. Але потім коли мені випала нагода попрацювати з ним вживу, виявилось що це правда. Те з якою він швидкістю працював в звичайному терміналі це було щось неймовірне. Він в звичайному «голому» солярісовському vi працював як в IDE паралельно редагуючи купу скриптів, відлагоджуючи і навіть unit-тестуючи їх не «відходячи від каси». От тоді я зрозумів що межі досконалості роботи навіть в самому простому терміналі не існує.
Щоправда цей чувак дійсно вмів користуватися клавіатурою. Зараз кого не спитай всі вміють друкувати всліпу, але клава без підсвітки не підходить. А цьому американцю, здається, не тільки підсвітка а й написи були непотрібні, він грав на ній як на баяні.

ага почитав. перевозять орків закордон. ну таке.... "оні же нє віноваты".

це добре. А як щодо дев центрів в рашці і білорашці? чи їх закрили? чи продовжують оркам платити зарплату?

а де ж JetBrains з усіма їх поробками? Чи ідея це свята корова?

Цей принцип справедливий незалежно від server/serverless підходу оскільки ключ може бути скомпроментований під час його передачі. Зрештою, у нас serverless виключно з точки зору runtime. Між запусками AWS Lambda мій zip архів з приватним ключем десь зберігається в AWS? Наскільки надійний цей сторедж? Хто і як може отримати до нього доступ?

Но серверлес функции не мутабельны

в даному котексті це не має значення, оскільки зловмиснику немає сенсу підміняти мій приватний ключ, йому просто потрібно його отримати для генерації власних сертифікатів.

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

Поэтому целесообразнее положить сертификат в сам серверлесс, хоть и придется его передать по HTTPS на Амазон.

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

Чи правильно я розумію, що на етапі

Далее создать zip-файл, в который положить серверлесс serverless.linux.amd64 (лучше назвать файл serverless), ваш ca-key и certonid.yml.

Далее этот zip-файл загружаем в AWS Lambda.

ми порушуємо базовий принцип

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