Хорошая новость для тех, кто пользуется Самбой – разработчики анонсировали версию 4.8, в которой заявлена полная совместимость с Active Directory (aka АД), добавлена в модуль kdc поддержка групповых политик для паролей, и применено исправление недавней уязвимости CVE-2018-1057, позволяющей любому авторизованному непривилегированному пользователю менять пароли других. Чуть подробнее – по ссылке: http://www.opennet.ru/opennews/art.shtml?num=48260

#samba #update

Vsphere persistent volume provisioning in k8s

Эй, буква! - спросите вы, чем ты там занимаешься последнее время что ничего интересного почитать не даешь?

Ну, в кратце новости, я недавно сменил работу и несколько недель привыкал к новому стеку - применял привычные мне инфраструктурные решения на кластер vmware. Самое интересное в этой истории - это то как я настраивал pv через нативный cloud provider. Все шаги целиком я не буду описывать, потому как есть несколько полезных статей где это уже сделано:
тыц: https://blog.mimacom.com/ocp-persistent-storage/
и тыц: https://cloud-provider-vsphere.sigs.k8s.io/tutorials/kubernetes-on-vsphere-with-kubeadm.html

после того как вы все настроите по статье, нужно будет сделать еще несколько моментов:

1) поддержка disk.UUID для виртуальных машин с vmware:

terraform:

resource "vsphere_virtual_machine" "vm" {
  enable_disk_uuid = "true"
...

или govc:
govc vm.change -json -vm.ipath="/path/to/VM" -e="disk.enableUUID=1"

Операция потребует перезагрузки после применения. Если этого не сделать, то диск будет присоединяться к виртуалке, но куб не сможет дальше примонтировать его к контейнеру.

2) если вы делали по статье выше, то нужна будет небольшая доработка, выполните пункт из документации:
https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/existing.html#on-the-kubernetes-workers

Что говоришь мальчик? почему бы сразу по ней не сделать? потому что во-первых она мне не в первую очередь попалась на глаза, во-вторых там идет какой-то ручник на мастере, вместо того чтобы сразу проинициализоровать, во-вторых и сам способ изменения systemd мне нрвится меньше чем правка /etc/default, поэтому в моем случае вместо того чтобы править systemd я добавил строчку KUBELET_EXTRA_ARGS="--cloud-provider=vsphere" в файл /etc/default/kubelet. Это логичнее и проще в автоматизации

3) выставляем корректные поля provider ID:
https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/existing.html#update-all-node-providerid-fields

и далее по статье можно шикарным способом прибить нужные контейнеры (контроллер, апи, перезапустить кублет). Если кластер не жалко проще всего сделать ребут или systemctl restart docker kubelet

4) Проверяем что все работает: https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/persistent-vols-claims.html
Здесь я привел пример со статикой, ибо с динамикой у меня с наскока сделать не получилось. Да, если у вас в организации права на кластер выдают гранулировано, то нужно попросить создать на некотором datastore папку и выдать на нее права Low level operations. Я видел статью где в миллион и одну картинку описано как настраивать все это дело (абсолютно не читабельно, поэтому пропустил, но сохранил в загашничек потому что очень информативно и вдруг пригодится). Так вот в ней на 100500 скриншотах описаны какие права надо выдать. Может вам в этой ситуации пригодится, мне повезло решить с нашими it-шниками вопрос и так.

5) если вы используете terraform

выставить при создании виртуальной машины такую директиву:

  lifecycle {
    ignore_changes = [
      disk,]
  }

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

#terraform #vsphere #kubernetes