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

Нет, именно это. Т.к. то "как действует панель" - может поменяться при малейшем ее апдейте совершенно молча. Вы, конечно, можете сказать что при каждом апдейте/релизе проверяете абсолютно все цепочки действий, которые потом предполагаете совершать руками. Или что вам персонально буквально о внутренних изменениях сообщают разработчики.

1) Как же вы "на вскидку не скажу" - если ранее уверяли что

- Значит не знаете, и это уже факт.

А вот это уже совсем плохо. Имеем неконсистетную "базу" для ispmanager. Получается три отдельных гранта вместо двух - в дальнейшем они могут обрасти еще и разными паролями/привилегиями.

Ситуация станет еще хуже - когда в один прекрасный момент панелька дорастет до более продвинутого контроля над mysql-пользователями (возможности указать хосты, вместо галки). И разработчики никак не смогут ее решить корректно при обновлениях. Единственный гарантированно работающий вариант - предположение о том, что помимо ispmanager никто никуда руками не лазит в его "базы" (т.е. конфиг апача и т.п.) и все делается через поддерживаемые интерфейсы (панельку, ее апи).

Дубль 15 - не может она поменять основные моменты. Просто не может и всё.

О каждом апдейте и изменениях мы знаем сразу. Если какие-то моменты не понятны, мы узнаём у разработчиков.

Снова чушь. Не имеет это отношения к обсуждению. Я знаю, что нужно сделать, чтобы панель корректно отобразила пользователей и базы. Остальное обсуждение не к месту.

Вы предлагаете сделать так, как панель не делает. Это не тоже самое, что "знаю, как делает панель". Мы не обсуждали, как поведёт себя панель, если что-то будет не так, как она хочет.

Вы вообще панель знаете, как устроена? Похоже нет.

В её случае либо обеспечить поддержку старых конфигураций, либо апдейтить все настройки под новый формат.

У панели НЕТ вещей, которые она хранит дополнительно, кроме распарсивания конфигов, кроме ispmgr.conf (который содержит общие вещи).

Поэтому никакой разницы, сделать запрос по API или самостоятельно поправить конфиги.

Дубль 16 - поменяет "неосновные". Клиенту легче не станет - он может и на "неосновных моментах" потерять не меньше бабла, при случае.

Что, и о том какие строчки в исходниках поменялись? Разработчики просто не включают информацию, которая не меняет документированное поведение панель, не меняет API, ими предоставленный.

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

Вы заметили, что "базы" я взял в кавычки. Вот такими "базами данных" для панели, если вы не вкурсе, и являются всякие конфиги апача. И да, конкретно в данном примере - основные проблемы вас поджидают при апдейте под "новый формат", т.е. поддержку user@remote вместо user@%.

Поэтому разница есть. API - это API, а база приложения - (как правило) таковым не является.

Разработчики форума, к примеру, не предполагают, что вы будете в штатном порядке лазить ручками в его базу. И не будут вам писать БАЛЬШИМИ БУКВАМЕ, что в этом релизе они все поменяли так-то и так-то. Вы об этом узнаете только когда полезете "как раньше", а получите "глюки".

myhand, пора, видимо, мне усомниться в ваших умственных способностях.

Судя по тексту, снова не представляете вообще о чём речь.

"Тыкальщик" ))) Никого вы не ткнули. Панель так не делает, как было в вашем примере. Как делает она мне известно.

Я уже не знаю, как вам писать... Какая нафиг разница, лазил я в базу в ручную до апдейта или нет?!? У меня юзеры будут такими, какими их видит панель. Поэтому апдейт не будет отличаться от апдейта на конфигурации, где ничего в ручную не трогали. Все изменения и новые "фичи" документируются. Вариант старого формата никто убирать не будет, поэтому работать оно будет успешно.

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

Думайте, что угодно. Понять, что вам пишут, вам, похоже, не суждено.

Всё, с вами обсуждение заканчиваю. Вы либо понимать не хотите, либо не получается.

Гм. У меня виртуальный хостинг внутри контейнеров XEN. Правда, тому есть одна очень большая и веская причина: мне проще потерять 2-8% производительности, чем разгребать обственные косяки или проблемы DDoS. например, при DDoS VDS может стать недоступен сам по себе, а вот с узла - вполне можно зайти и оценить ситуацию. На OVZ или KVM я такое сделать бы не рискнул. Плачу - потерей производительности, да лишним гигабайтом памяти. Получаю - быструю переносимость в случае необходимости переезда на другое железо + удобство управления. Т.е. сам по себе xen устанавливался только для одного единственного контейнера.

Ровно до обновления этой панели. Я на полном серьёзе. Лазить в конфиги руками в обход панели - чревато проблемами при обновлениях функционала панели. И это просто одна из парадигм, рождённая самой идеей панелей управления. Просто разработчики делают это по-разному... На самом деле, я сейчас для внутренних целей пользуюсь одной панелькой, и очень сильно наблюдаю такую проблему: она у меня начинает лазить в новые конфиги, при очередных апдейтах... И очень интересные вещи бывают. Вы, конечно, можете вносить аналогичные изменения в конфиги, что делает и панель - но нафига? В том и проблема, что в обход панели в конфиги лезут, чтобы сделать что-то не тривиальное, или недостижимое средствами панели.... А когда это что-то становится достижимо средствами панели - здравствуйте мои любимые и дорогие грабли.

Да ёпрст.

Какие проблемы, если я на 100% знаю, какие изменения делает панель в системе при нажатии на кнопку?

Зачем говорить про "одну панельку", если я говорю про конкрентую панель, которую поддерживаем уже много лет при тесных контактах с разработчиками?

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

В том и проблема, что вы говорите только про неё. О других панелях вы либо ничего не знаете, либо не в состоянии рассуждать о чем-то, что вам известно мало (т.е. промолчать).

Вот ссылка на пост. /ru/forum/comment/10027084

Вы прямо таки навязываете эту панель. И всем глубоко плевать, как вы её знаете, видите ли... А между прочим, человеку как оказалось, гораздо нужнее не платить деньги, а понимать. А покупка панели, которая якобы решает все проблемы - лишь ваша идея. Ничего более. Мало того, что она очень ущербна в плане некоторого функционала, так она еще и платная. Я понимаю, что кому-то она удобна и правильна. но то, что она - единственное решение в своём роде - плод вашего воображения. Я могу привести много примеров, когда использование ISP становится камнем преткновения. Для простого пользователя. Или для небольшой веб-студии, которая не держит своего админа на постоянке...

Так что давайте поймём, что у проблемы бывает множество решений. Ну и, кстати. Я сужу на основе ISPManager на основе той самой одной панельки, для вашего сведения. И принцип действия всех подобных программных продуктов, а так же векторы и принципы развития - почти одинаковы. Это аксиома, которую вам придётся принять, потому как её доказать невозможно... Дело в том, что вы далеко не программист. Хотя, любому системному администратору нужно знать, как пишутся программные продукты и что может произойти, если разработчик не предусмотрел криворукого пользователя (в данном случае пользователем является администратор).

Теперь поехали дальше. То, что вы знаете сейчас - не говорит о том, что это будет верно в будущем. При очередном обновлении может произойти всякое. Вплоть до фейка разработчика. И mysql - всего лишь пример, который, в общем-то, скорее всего, будет не актуален, т.к. я не вижу с точки зрения программиста никаких камней преткновения, чтобы обновить всё "правильно". Но (!), зная, как работают программисты в ISPSystem - боюсь, что там может произойти всякое. А вот простейшее расширение функционала вполне может вылететь в проблему там, где её не ждали. Взбредёт им блажь в голову рулить тем же spamassassin через панель более глубоко - боюсь, что при очередном апдейте те пользователи, которые им пользовались могут нарваться на неприятности. Или грейлистинг - вздумают они настраивать параметры... И попадос... :). Дело в том, что все мы люди. Это раз.

А ещё момент - по себе судить не следует. То, что хорошо вам - другому человеку, особенно не сведующему в администрировании, может показаться сущим адом. Я не просто так это говорю. Я это заявляю на основании моего поыта, который говорит мне "что русскому хорошо - то немцу смерть". Вы, например, предлагаете всем пользователям, включая грейлистинг почты на exim, лазить в конфиги? Это нормально? А если они не знают, где это и как? Ну вот как у ТС, знаний чтобы скачать инсталлер и запустить - хватит, а дальше уже - всё, приехали....

Так что если "для себя" - то вполне сначала стоит научиться работать без панели. А потом уже...

P.S. продажник тем и отличается от специалиста, что специалист сначала выяснит, что же надо потенциальному клиенту и даст ему ровно то, что ему нужно. А продажник - просто спихнёт ему то, что как ему кажется, клиенту будет достаточно. Тем паче, что данная тема прямо яркий пример. ТС поставил ISPConfig, насколько я сумел прочитать. И самообразовывается. В отличии от того, который просто считал бы, что кроме ISPManager больше ничего нет. Ах, каково было удивление одного из моих клиентов, когда я вкатил ему русифицированный и модифицированный мною kloxo... Он прямо обрадовался, что есть панельки бесплатно и так милые глазу, да и более функциональные :). Чего только стоит парковка доменов в ISPManager... Или установка лишних плагинов, чтобы залезть в консоль... Ах, а как тяжело настраивать грейлистинг... Ну и не лишним будет упомянуть о том же любимом всеми disable_functions в php - у некоторых даже продумано и это, да и по умолчанию много опасного зарезано... И т.д. и т.п.

Скрин1

скрин2

Сравните возможности. Может быть, кому-то надо именно это? именно ширина тюнинга без прибегания к правке конфигов, установка xcache без залезания в консоль...? Или, может, нужно что-то навроде DirectAdmin... Или ещё чего? :). Ну нюансов всегда много. Я просто пытаюсь показать, что на ISP свет клином не сошёлся.

---------- Добавлено 15.02.2012 в 12:55 ----------

P.P.S. То, что я показал в выключении функций php работает даже на cgi/fcgi (от таки дела).

1. У панели есть список обновлений и какие модули оно затрагивает.

Основной функционал практически никогда не меняется. В основном это новые фичи или исправления в работе.

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

Не всё делается без панели. Включение функций делается как раз средствами панели.

Я лишь говорю про то, что можно сделать не прибегая к API. (поменять ip-адреса при их изменении, поменять массово какие-то настройки).

Через API это займёт кучу времени и шансы в разы возрастают получить проблемы.

2. Мне не нужно ничего делать или забывать. У нас работает сейчас достаточно сотрудников, чтобы у каждого были свои задачи. (слежение за уязвимостями, обновлениями и т.п.)

Это разве не расширение функционала панели?

---------- Добавлено 15.02.2012 в 13:22 ----------

А сотрудник ошибиться не может?

---------- Добавлено 15.02.2012 в 13:27 ----------

Кстати, самое главное... А зачем нужна такая панель?

Так он жеж дырявый