1) Нет подобной возможности нету. И если честно, мы даже над ней не думали.
2) Для данной задачи больше подходят систему управления версиями (в планах было добавить поддержку git), нежели файловый менеджер. Там где это необходимо можно будет контролировать изменение файлов через git.
В 2010 году мы не смогли найти двухпанельный web файловый менеджер, который нас так или иначе устраивал. Я не исключаю, возможно плохо искали. Единственно, что понравилось — это запуск web консоли и mc внутри, но это не совсем то, что нам было нужно. Перечислять аналоги NetFTP не вижу особого смысла.
На текущий момент около 1500 тестовых аккаунтов (за 2 дня). На хостинге в день до 1000 человек в FM заходят. По тестированию и безопасности сильно помогли, хорошая обратная связь. Спасибо !
Почему кнопка обновления на лого РКН похожа, кстати?
Не обращал на это внимание, но не думаю что РКН будет возражать =)
также хотел заметить, одна из TODO — это добавить web терминал, который будет работать с правами пользователя. Но, в любом случае, будем рады, если присоединитесь к разработке и поможете нам сделать Sprut.IO лучше.
Я не очень понимаю о чем Вы говорите — на хостинге пользователи тоже могут смотреть /etc зайдя по SSH. На /etc стоят права 755 и это нормально для Linux (это права по умолчанию). А вот на homedir уже стоит 700 и зайти к нему в директорию Вы не сможете (если сам пользователь не поставит другие права).
Если Вы хотите, что бы пользователи не делали листинг файлов — ставьте права 711 на /etc. Но при 700 перестанет работать резолвер, определение логина, переменные окружения, профайлы и куча всего.
Если пользователь имеет права на чтение директорий или файлов — эти же директории или файлы можно прочитать из файлового менеджера. Пользователь должен иметь доступ к /etc (так же как и к /etc/passwd). В Sprut.IO надо в принципе убрать понятие домашнего FTP или добавить настройку которая позволяет/запрещает выход из домашней директории. Основное ограничение все таки это права пользователя в системе — остальное для удобства пользователя. В принципе это эквивалентно тому как если Вы зайдете по SSH на сервер.
Спасибо, в планах выложить еще несколько проектов в OpenSource. Но не хватает времени и сил для приведения их в адекватный вид (чтобы ими могли пользоваться не только мы). В любом случае будем стараться. Хотим в течении нескольких лет прийти к тому, что бы выложить панель в OpenSource — но это очень долгосрочные планы.
Нет не правильно — RAID (soft, hard) не используем, как раз из-за описанных Вами причин. Если умер диск — это не критично, так как у пользователя гарантированно есть бэкапы на других дисках (и обязательно на другом хранилище) и даже смерть всей полки не приведет к отсутствию бэкапов + на большинстве серверов есть локальные бэкапы, но они скорее для нас чем для пользователей.
Если рассматривать кол-во допустимых отказавших дисков, то RAID6 c hotswap на одной полке был бы в разы надежнее.
Перестройка массива будет идти очень очень медленно, а если учесть что на массив будет идти запись и диски могут быть не самые новые (или новые, но очень медленные), перестроение будет идти до момента пока N дисков не умрет и весь массив не развалиться. RAID6 c hotswap на 24 дисках по 6 терабайт — не самая хорошая идея.
Как дополнительный плюс, используя каждый диск по отдельности можно использовать диски любого размера и скорости.
Скажет, к тому же BeGet идут из-за цен, а не из-за надежности
Для бэкапа большой производительности процессора в нашем случае не нужно, все упирается в диски. RAID не используем, данные бэкапятся минимум на два хранилища (через день) — отказ целой полки неприятен, но не критичен. Как следствие данное решение вполне подходит для наших задач.
Потребление полки с дисками по нашим замерам получается порядка 450-550 ватт (диски WD Red 6Tb) + сервер 250 ватт в пике. Менее 6 киловатт на стойку.
2) Для данной задачи больше подходят систему управления версиями (в планах было добавить поддержку git), нежели файловый менеджер. Там где это необходимо можно будет контролировать изменение файлов через git.
Не обращал на это внимание, но не думаю что РКН будет возражать =)
Если Вы хотите, что бы пользователи не делали листинг файлов — ставьте права 711 на /etc. Но при 700 перестанет работать резолвер, определение логина, переменные окружения, профайлы и куча всего.
Если пользователь имеет права на чтение директорий или файлов — эти же директории или файлы можно прочитать из файлового менеджера. Пользователь должен иметь доступ к /etc (так же как и к /etc/passwd). В Sprut.IO надо в принципе убрать понятие домашнего FTP или добавить настройку которая позволяет/запрещает выход из домашней директории. Основное ограничение все таки это права пользователя в системе — остальное для удобства пользователя. В принципе это эквивалентно тому как если Вы зайдете по SSH на сервер.
Так же наш технический директор moosy обещал собрать deb пакетики.
В интерфейс переключение языков не выносили, так как у нас оно соответствует языку в панели управления. На текущий момент можно поменять язык в файле конфигурации https://github.com/LTD-Beget/sprutio/blob/master/app/config/settings.py
Переключение языков нужно добавить в интерфейс.
пс. зачем же в демо фильмы грузить...
Перестройка массива будет идти очень очень медленно, а если учесть что на массив будет идти запись и диски могут быть не самые новые (или новые, но очень медленные), перестроение будет идти до момента пока N дисков не умрет и весь массив не развалиться. RAID6 c hotswap на 24 дисках по 6 терабайт — не самая хорошая идея.
Как дополнительный плюс, используя каждый диск по отдельности можно использовать диски любого размера и скорости.
Для бэкапа большой производительности процессора в нашем случае не нужно, все упирается в диски. RAID не используем, данные бэкапятся минимум на два хранилища (через день) — отказ целой полки неприятен, но не критичен. Как следствие данное решение вполне подходит для наших задач.
Потребление полки с дисками по нашим замерам получается порядка 450-550 ватт (диски WD Red 6Tb) + сервер 250 ватт в пике. Менее 6 киловатт на стойку.