Согласен, в свое время предпочел kvm, из-за его нативности, без необходимости в патченом ядре. Думаю как и многие.
Что примечательно, сейчас есть такая же тенденция с OpenVZ и LXC. И я посмеюсь, если в скором времени появиться статья «Почему OpenVZ не стала новой Red Hat...»
в случае падения какого-либо из них — скрипт автоматически добавляет кубик-динамит и взрывает его
Лучше взрывающегося крипера, с таким звуком будет эффектнее :)
Идея для визуализации данных: статистика самих серверов Minecraft
На вопрос какое видео ваше
Делаю ставку на то, которое справа, под №1.
Тому, что на левом видео, было интереснее попрыгать по фигурам по всем этим, а тому что на правом скорее продемонстрировать их. Ну и к тому же потому, что оно первое
В nginx ваша ошибка лечится указанием директивы: client_max_body_size
Тормоза могут быть первое время из-за сканирования движком большого объема файлов, а вообще как я уже писал выше, очень советую подключить облако к MySQL и Redis.
Костыль — не костыль, к большому сожалению мало кто реализует защиту от брутфорса в своих продуктах.
Все чаще приходится использовать Fail2Ban чуть ли не для всего.
Банальный пример: OpenSSH тоже не имеет встроенной защиты от брутфорса.
Windows не подключает WebDAV если подключение не защищено, или имеет невалидный сертификат, без специального ключа в реестре.
Попробуйте поменять http на https в ссылке и проверить сертификат, скорее всего у вас все получится.
Используем ownCloud в продакшене, объемы не большие (максимум 50 человек), но из всех решений оказалось наиболее зрелое. Пробовал еще seafile, pydio и некоторые другие, у каждого свои недостатки.
Для ownCloud используем nginx+fastcgi, mysql, redis, авторизация через ldap, хранение файлов на файловой системе. Последние установки делаем в docker.
Могу сказать, что подключение mysql и redis дает существенный прирост в производительности.
Отвечу сам на свой вопрос:
Можно вести отдельную бд для каждого пользователя и какой-нибудь файл с мета-информацией, например когда было последнее изменение от пользователя. Потом движком проверять эти файлы, и строить из этого всего ответ на трубуемый запрос.
Например если мы говорим о форуме:
Запрос от пользователя будет содержать информацию о том с какой и по какую дату подгрузить сообщения, и движку придется сканировать только те файлы, в которых хранится метаинформация об измении за это время.
В дальнейшем можно будет обязать движок вести свою отдельную бд с метаданными об изменении от пользователей.
Еще бд, которая будет отображать поправки модераторов, удаленные сообщения и т.п.
Интересно, насколько данная реализация будет накладной по ресурсам? — Есть идеи получше?
в манифесте к сайту указывается, что запись в определенную папку могут иметь пользователи со своими ключами а не только обладатель основного ключа.
Все очень интересно, но как с помощью данного подхода можно организовать хотя бы простейшую файловую бд? Как она будет вести себя при обновлении информации одновременно на разных хостах — как же репликация?
Интересно, а всякие Avira и Bitdefender устанавливаются рядом и имеют свой интерфейс управления? — иконки в трее? — или 360 Total Security как-то хитро прячет их?
Как устроена интеграция с этими продуктами?
в самом протоколе не предусмотрена доставка сообщений оффлайн-юзерам и маркировка кому доставлено кому нет
В Jabber это работает немного подругому. У мультиюзер чатов в Jabber больше общего скорее с IRC, чем с обычным протоколом Jabber, отсюда все вытекающие. Реализация данной функции ложится целиком на клиента. Если пользователь зашел в chat room, клиент обычно подгружает n'ное кол-во последних сообщений с сервера.
Что касается Jappix, из того что я протестил, мультиюзер чаты работают довольно стабильно, можно настроить персистентные комнаты, автоподключение и хранение логов. Логи подгружаются автоматически, но до последующего рестарта сервера. После рестарта, комната меняет свой ID, и Jappix уже не подгружает логи. Но всю историю комнаты по прежнему можно получить через встроенный веб-сервер.
7. Хабрахабр — пишем статьи о программировании и системном администрировании...
Компании, готовые оплатить ваши статьи в их корпоративном блоге, сами на вас выйдут.
Что примечательно, сейчас есть такая же тенденция с OpenVZ и LXC. И я посмеюсь, если в скором времени появиться статья «Почему OpenVZ не стала новой Red Hat...»
Идея для визуализации данных: статистика самих серверов Minecraft
Тому, что на левом видео, было интереснее попрыгать по фигурам по всем этим, а тому что на правом скорее продемонстрировать их. Ну и к тому же потому, что оно первое
Тормоза могут быть первое время из-за сканирования движком большого объема файлов, а вообще как я уже писал выше, очень советую подключить облако к MySQL и Redis.
Все чаще приходится использовать Fail2Ban чуть ли не для всего.
Банальный пример: OpenSSH тоже не имеет встроенной защиты от брутфорса.
Попробуйте поменять http на https в ссылке и проверить сертификат, скорее всего у вас все получится.
Для ownCloud используем nginx+fastcgi, mysql, redis, авторизация через ldap, хранение файлов на файловой системе. Последние установки делаем в docker.
Могу сказать, что подключение mysql и redis дает существенный прирост в производительности.
Истинно виндусовый шелл — это PowerShell
Теперь можно хранить свои windows-"dotfiles" в github так же просто как и в *nix.
Даже нет, проверять файлы изменений от пользователей, и строить из этого одну общую бд — вот оно! :)
Можно вести отдельную бд для каждого пользователя и какой-нибудь файл с мета-информацией, например когда было последнее изменение от пользователя. Потом движком проверять эти файлы, и строить из этого всего ответ на трубуемый запрос.
Например если мы говорим о форуме:
Запрос от пользователя будет содержать информацию о том с какой и по какую дату подгрузить сообщения, и движку придется сканировать только те файлы, в которых хранится метаинформация об измении за это время.
В дальнейшем можно будет обязать движок вести свою отдельную бд с метаданными об изменении от пользователей.
Еще бд, которая будет отображать поправки модераторов, удаленные сообщения и т.п.
Интересно, насколько данная реализация будет накладной по ресурсам? — Есть идеи получше?
Все очень интересно, но как с помощью данного подхода можно организовать хотя бы простейшую файловую бд? Как она будет вести себя при обновлении информации одновременно на разных хостах — как же репликация?
Правильно ли я понимаю, что HTTP/2 так же решает проблему размещения нескольких сайтов защищенных SSL-сертификатами на одном IP-адресе?
Как устроена интеграция с этими продуктами?
В Jabber это работает немного подругому. У мультиюзер чатов в Jabber больше общего скорее с IRC, чем с обычным протоколом Jabber, отсюда все вытекающие. Реализация данной функции ложится целиком на клиента. Если пользователь зашел в chat room, клиент обычно подгружает n'ное кол-во последних сообщений с сервера.
Что касается Jappix, из того что я протестил, мультиюзер чаты работают довольно стабильно, можно настроить персистентные комнаты, автоподключение и хранение логов. Логи подгружаются автоматически, но до последующего рестарта сервера. После рестарта, комната меняет свой ID, и Jappix уже не подгружает логи. Но всю историю комнаты по прежнему можно получить через встроенный веб-сервер.