Это всё тот же баг, что обсуждается уже не первый день — обновите Вы уже наконец на всех серверных и клиентских машинах библиотеку OpenSSL, до последней версии (в старых кстати бага тоже не проявляется).
Если требуется периодически рассылать какие-то спам новости, то предпочтительнее и удобнее использовать сторонний сервис. А одиночные уведомления или личные письма со своего почтового сервера.
Под «свои» внутренние нужды конечно использовать можно. По крайне мере получаешь видимость контейнерной виртуализации и свои пакеты/настройки/ip-адреса и т.п. для каждой «виртуалки».
В общем «под внутренние задачи» на отдельном сервере вполне годная штука.
Должно быть — наверное да. Но пока как видите оно не пашет, как и косяк указанный мной выше, он и основополагающим командам(start, stop, shutdown) не даёт нормально работать.
IMHO, контейнеры прекрасно создаются командой debootstrap (ну это для Debian'f разумеется). backup/restore вообще не очень понятны, когда это действительно одна папка с rootfs, так что сами вызывайте что Вам удобнее — tar, dump, etc.
Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!
Если это рядовая проверка(случайный выбор пассажира), а не целенаправленная «облава», то с вероятностью 99% ни кто и не подумает снимать копию с накопителя. А так сказать «особые» случаи и рассматривать надо отдельно…
Это всё равно, что рассуждать, что сам по себе карандаш писать не будет, ему нужно(ен) что-то(кто-то) что(кто) будет его применять.
PKI в контексте ssh аутентификации по ключам заменяет заранее известный fingerprint сервера (отнесённый ручками, прописанный в DNS, и т.п.), а не то что публичный ключ оказался на сервере. Должны же быть хоть какие-то начальные условия.
Типичный пример, аутентификация по ключам в SSH.
Вообще процессы аутентификации и идентификации очень тяжело разделить, но всё же эта грань в теории существует, на практике же они слиты воедино.
Открытый ключ… не может служить средством аутентификации
Эм… Вы перепутали понятия. Криптография как раз таки и решает задачу аутентификации. И в чистом виде (без PKI, например) не может решить задачу идентификации.
Мде, что бы поменять порт на отличный от 443 надо лезть в реестр
If you want to configure the SSTP-based VPN server to listen on a port other than TCP port 443, follow these steps:
Start Registry Editor, and then locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\
In the details pane, right-click ListenerPort, and then click Modify.
Click Decimal, type an alternative port number such as 5000, and then click OK.
Exit Registry Editor, and then restart the Routing and Remote Access service.
Note If you change the ListenerPort value, you must configure the NAT device to forward TCP port 443 traffic to the new port number that you configured. For example, you must configure the NAT device to forward incoming traffic on TCP port 443 to TCP port 5000 on the SSTP-based VPN server.
Читаем про dll(для Windows), so(Linux). Читаем про опции компиляции --with-XXX.
Ну и пускай вот этот proof link.
В общем «под внутренние задачи» на отдельном сервере вполне годная штука.
Раздражает то, что многие команды привязаны к той мысли, что контейнеры должны лежать в /var/lib/lxc/${cname}/rootfs, а если не в rootfs, а просто в ${cname}, то часть команд не работает, даже если в конфиге указан верный путь! Почему бы не брать настройку из файла настроек?!
PKI в контексте ssh аутентификации по ключам заменяет заранее известный fingerprint сервера (отнесённый ручками, прописанный в DNS, и т.п.), а не то что публичный ключ оказался на сервере. Должны же быть хоть какие-то начальные условия.
Вообще процессы аутентификации и идентификации очень тяжело разделить, но всё же эта грань в теории существует, на практике же они слиты воедино.
Start Registry Editor, and then locate the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SstpSvc\Parameters\
In the details pane, right-click ListenerPort, and then click Modify.
Click Decimal, type an alternative port number such as 5000, and then click OK.
Exit Registry Editor, and then restart the Routing and Remote Access service.
Note If you change the ListenerPort value, you must configure the NAT device to forward TCP port 443 traffic to the new port number that you configured. For example, you must configure the NAT device to forward incoming traffic on TCP port 443 to TCP port 5000 on the SSTP-based VPN server.