Панель управления сервером

Не писать в свой конфиг, а считывать и показывать права из таблиц мыскла. И нехрен велосипед изобретать. Эдакий а-ля PHPMyAdmin. ИМХО.

Какой такой "свой конфиг"? Если я не ошибаюсь, в роли такового у ispmanager именно "права из таблиц мыскла" и используются.

myhand, Вот не знал я, пишет оно еще куда-то или нет. Не нашёл. Значит, не вижу проблем при обновлении, даже потенциальной. Всего-то зарядить текстовое поле рядом с галкой и связать его содержимое при получении с одним запросом БД, при отправке - с другим. Предварительно проверив корретность введенных данных.

Не могу сказать, вот bsd - не гонял особо. Ни разу не было нужно. Да и юзкейс не понятен, зачем оно в виртуалке может потребоваться.

ну согласен, плюс. не факт что сильно значимый, но плюс.

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

Глубинный смысл?

Так как раз процентов 80 тех виндов х64. Радуемся жизни, ничего никуда не улетает.

Ну нет так нет. Когда выбирали систему виртуализации, основным аргументом было что KVM ныне мейнстрим, по крайней мере с точки зрения rhel. И на кой надо выбирать свой отдельный особый путь против течения - не понятно. На ум приходят чудо товарищи, ставящие генту в датацентрах и хостинг-компаниях, любители ядра покомпилять на пару с фрибсд-шниками..

юзкейс такой же как и у линя.

Последний раз видел полгода назад. Кстати, то. что у разрабтчиков обычно не грузит. Грузит продакшн. Это когда виртуалка отбирает всё i/o от хост-машины. Возможно, мне не повезло, но осадок остался.

Да, я же сказал - специфические задачи. Немного поясню: системы реального времени. Они должны гарантированно получить минимальный объем процессора, но они прожорливы, потому имеет смысл зарезать. В случае с найсом гарантий нет (!).

Полгода я его не трогал. Какая версия КВМ? KVM USB-passthrough+принтер=BSOD. Опять же с AMD оно не больно дружит. Много памяти (свыше 4 Гб может привести к синему экранчику... Проброс etoken - вообще песня отдельная. Со слезами.

Попросите кого-нибудь эмулировать работу с памятью, чтобы прокачивать хотя бы 10 гбит в секунду. На нагруженной ноде. Тогда поговорим. Через 6-10 часов ваша система с большой долей вероятности (не всегда) уйдёт в ступор до снятия нагрузки изнутри ВМ. Убить такое не получалось. Правда, не на всякой железке получится, но вот на десктопных матерях с кривым acpi еще и не такое можно увидеть.

P.S. вы разве не знали, что KVM "капризно" к железу?

P.P.S. Когда я выбирал виртуализацию - всё было намного печальнее. Вот, просвещайтесь: http://www.linux-kvm.org/page/TODO

Не согласен. BSD менее удобно ставится/саппортится на большом количестве машин. Классический флейм ports vs rpm. imho, разумеется.

Осадок - это да. Психология. Сильная штука. Кроме шуток.

Вы системы реального времени отлаживаете в виртуалках?

И все вот это вот прекрасно работает. Правда етокен правильнее через rdp пробрасывать, а не воткнутым в сервер держать.

Дай софтину/скрипт - не поленюсь тест прогнать.

На кривом железе можно глюков увидеть везде. С виртуализацией и без оной. Но мы же сервера под серьезные задачи собираем на нормальных платформах, а не из говна и палок?

Это интересно. Рассмотрите такой сценарий, например: на сервере уже был создан руками аккаунт user@remote. Наш "гуру" выше написал, что панель его (пользователя) не тронет и не увидит. (Хотя хз, тут он порой такие логические кренделя выделывает, что доверять его знаниям я бы не стал: "Панель так не делает, как было в вашем примере. Как делает она мне известно." (c)).

Но вот пришел апдейт - теперь панелька аккаунт увидит. Что ей (т.е. разработчикам) делать?

А что? Плохо, чтоли?

Кривой сервер LineAge на яве у клиента был. Вот на паре EQ9 убедились, потом попросили съехать.

Как давно USB 2.0 появилось в KVM? А PCI пробрасывать уже тоже можно? Я, кстати, не верно выразился. Не etoken. HASP. 1С в виртуалку пихали.

Ну как. Ниче не делать. Показать как есть. Оно ж само не ведет своих баз данных. Оно просто спрашивает у скуля. Вот и показать, что этот юзер есть и юзер это user@remote. Хотя как оно никуда не пишет, а откуда берётся принадлежностью юзеров к аккаунтам в панели? Оп-па... Значит надо всё просканировать и найти пользователя в панели по привязке нашего юзера к БД. В данном случае, проще продолжать его не видеть, ИМХО.

Надо отталкиваться от текущей логики панели, я тут не совсем компетентен, но подозреваю, что выше я был не прав. Нужно "оставить всё как было". Админ он лучше знает, что его системе надо. Т.е. и юзверя как и раньше лучше не видеть.

Для этого надо сперва прекратить детсад с "моя база данных - конфиги апача и пр." :)

У директадмина база на файлах. Проблем нет.

У ISP подход как у whm, и тоже проблем нет.