VPS + Wp + W3 Total Cache - оптимизация

Ъмммммм .. нещо ти чупи сайта при първо зареждане. Отвори го в хрома под инкогнито моуд (ctrl+shift+n).

Избягвай да качваш .png изображения, защото са огромни по размери.
 
От: VPS + Wp + W3 Total Cache - оптимизация

Всичко това, което казваш за варниш беше направено. И пак си крашваше. И ти казвам, че това бяха 8 ядра с по 32гб рам и ссд-та. Вярно, че сайта беше доста натоварен, но като е толкова натоварен се търсят други решения, а на клиентите просто не им се плащаше повече. И си го караха така. И още нещо - ние предлагаме хардуера, всеки си прави каквото иска със софтуера. Те си го инсталираха и те си го настройваха. От нас се искаше да проверим дали нещо не му е наред, че крашва толкова много. Наред си беше всичко, просто ... проблеми със стабилността. Както и да е с варниша ти казах,че сме го слагали на доста машини, къде има подобрение - къде не... зависи от натовареността, апликацията и още куп други неща.

Колкото до cPanel на нас доста бързо ни оправят проблемите, но ти ми говориш за нещо различно - ти говориш не за съпорт а за оправяне на проблеми с кръпки, т.е. пуснали са някаква версия , оказало се, че има бъг в нея и чакаш кръпката за да се оправи бъга. Това е разликата м/у обикновения потребител и корпоративния - на нас не ни се налага да чакаме тези неща, а се оправят веднага. Това, което ми го говориш за phpmyadmin няма нищо общо със cPanel :) Паролата за системния потребител и паролата за базата данни нямат нищо общо :) потребителя е длъжен да си ги смени сам. Защото потребителя може да има 3-4-5-6-10-100 бази данни с още толкова разлчни пароли. В такъв случай cPanel коя по-точно парола да синхронизира? И това phpmyadmin все пак е 3rd парти софтуер и в договора , който сключваш със cPanel е, че нямаш подръжка на софтуера от 3-ти страни. Но все пак това което ти ми каза не е бъг :) След като това те дразни защо не добавиш един вхост специално за phpmyadmin и при създаване на нов потребител да се добавя алиас от типа "dbadmin.domain.com"? Където да се пренасочат заявките към редовно ъпдейтнат phpmyadmin ? :) Например само идея давам де...

Моят уордпрес - http://tools.pingdom.com/fpt/#!/dwVjiU/https://www.ezservices.eu/
 
От: VPS + Wp + W3 Total Cache - оптимизация

Нещо взехте пак на китайски да говорите. Да се върнем на темата, като за по-прости хора. Моя сайт го зарежда за около 5 секунди, доколкото виждам от теста, повечето си зарежда снимчици (то има доста): http://tools.pingdom.com/fpt/#!/eydHud/iskamdaznam.com

Човече - стартовата ти страница е 1,9 мб... няма как да ти е бърз сайта...
 
От: Re: VPS + Wp + W3 Total Cache - оптимизация

Ъмммммм .. нещо ти чупи сайта при първо зареждане. Отвори го в хрома под инкогнито моуд (ctrl+shift+n).

Избягвай да качваш .png изображения, защото са огромни по размери.

Е с това вече ме закопа. Идея си нямам защо така, аз chrome не ползвам, пък това инкогнито даже не го знам какво е, затова съм го пропуснал този проблем.

Човече - стартовата ти страница е 1,9 мб... няма как да ти е бърз сайта...

Така, е картинки много, той винаги е бил така. Но всъщност при сърфиране си се отваря много бързо (или поне би трябвало).
 
От: Re: VPS + Wp + W3 Total Cache - оптимизация

Така, е картинки много, той винаги е бил така. Но всъщност при сърфиране си се отваря много бързо (или поне би трябвало).

Разбира се, в БеГе ще се отваря бързо, но от чужбина... Тук всички доставчици са ербап - даваме гигабит интерет неограничен и веднага в скобите - за извън БГ са лимитирани на 2-3-5 мбит/с.
 
От: Re: VPS + Wp + W3 Total Cache - оптимизация

Разбира се, в БеГе ще се отваря бързо, но от чужбина... Тук всички доставчици са ербап - даваме гигабит интерет неограничен и веднага в скобите - за извън БГ са лимитирани на 2-3-5 мбит/с.

Няма такова голямо значение от чужбина, сайта е бг, малко са чужденците, които го следят, а тях няма да ги сбъркат 2-3 секунди повече за пълното зареждане. Разбира се, би било чудесно за хвърчи навсякъде за по 2 секунди, но с толкова картинки и съдържание не виждам как.
 
От: VPS + Wp + W3 Total Cache - оптимизация

Нещо взехте пак на китайски да говорите. Да се върнем на темата, като за по-прости хора. Моя сайт го зарежда за около 5 секунди, доколкото виждам от теста, повечето си зарежда снимчици (то има доста): http://tools.pingdom.com/fpt/#!/eydHud/iskamdaznam.com

Имаш един проблем. На боди тага имаш бек граунд , който ти генерира 404 и съответно 2-ри път зарежда уордпрес:

body {
font: 13px "Helvetica",Helvetica,Geneva,Arial,sans-serif;
color: #333;
background: url('http://iskamdaznam.com/wp-content/plugins/wptouch-pro/themes/classic/iphone/images/backgrounds/ipad-thatch-light.png') repeat scroll 0px 0px #CCC;
}


Провери пътя на снимката дали е правилен.
 
От: VPS + Wp + W3 Total Cache - оптимизация

Това къде точно го видя? Аз не го виждам. а wptouch беше един плъгин за мобилна версия, който отдавна го няма, чудно откъде го изкарва
 
От: Re: VPS + Wp + W3 Total Cache - оптимизация

Ъмммммм .. нещо ти чупи сайта при първо зареждане. Отвори го в хрома под инкогнито моуд (ctrl+shift+n).

Избягвай да качваш .png изображения, защото са огромни по размери.

При проба излиза, че при активиране на page cache почва да го омазва, интересно защо.
 
Re: От: VPS + Wp + W3 Total Cache - оптимизация

Всичко това, което казваш за варниш беше направено. И пак си крашваше. И ти казвам, че това бяха 8 ядра с по 32гб рам и ссд-та. Вярно, че сайта беше доста натоварен, но като е толкова натоварен се търсят други решения, а на клиентите просто не им се плащаше повече. И си го караха така. И още нещо - ние предлагаме хардуера, всеки си прави каквото иска със софтуера. Те си го инсталираха и те си го настройваха. От нас се искаше да проверим дали нещо не му е наред, че крашва толкова много. Наред си беше всичко, просто ... проблеми със стабилността. Както и да е с варниша ти казах,че сме го слагали на доста машини, къде има подобрение - къде не... зависи от натовареността, апликацията и още куп други неща.

Колкото до cPanel на нас доста бързо ни оправят проблемите, но ти ми говориш за нещо различно - ти говориш не за съпорт а за оправяне на проблеми с кръпки, т.е. пуснали са някаква версия , оказало се, че има бъг в нея и чакаш кръпката за да се оправи бъга. Това е разликата м/у обикновения потребител и корпоративния - на нас не ни се налага да чакаме тези неща, а се оправят веднага. Това, което ми го говориш за phpmyadmin няма нищо общо със cPanel :) Паролата за системния потребител и паролата за базата данни нямат нищо общо :) потребителя е длъжен да си ги смени сам. Защото потребителя може да има 3-4-5-6-10-100 бази данни с още толкова разлчни пароли. В такъв случай cPanel коя по-точно парола да синхронизира? И това phpmyadmin все пак е 3rd парти софтуер и в договора , който сключваш със cPanel е, че нямаш подръжка на софтуера от 3-ти страни. Но все пак това което ти ми каза не е бъг :) След като това те дразни защо не добавиш един вхост специално за phpmyadmin и при създаване на нов потребител да се добавя алиас от типа "dbadmin.domain.com"? Където да се пренасочат заявките към редовно ъпдейтнат phpmyadmin ? :) Например само идея давам де...

Ти даже не разбра къде е проблема... ужас да си върнете cpanel сертификацията и да си искате прасето направо ми е жал за клиентите ви, а ти написа пълна глупост....

Ето така трябва да работи при смяна на парола и така е работило от години (даже обикновените cPanel потребители могат да потвърдят че при смяна на паролата за акаунта сменя тази на master юзера на базата на акаунта и автоматично се отваря phpmyadmin без парола и виждаш всички бази в този акаунт



attachment.php

password-modification.png

Промяната на паролата работи така през апи кол и при смяна през WHM и не работи през самия cpanel като клиента си я сменя от късна версия 11.42 насам не я синква

Админстрирам cPanel сървъри в сащ и канада от 2005 година и много добре знам какво говоря... винаги я е синквало откакто се занимавам...

A да говориш за корпоративни клиенти и съпорт сега ходих да проверя :) бъга присътва и при компания която е в средата на топ 10 NOK препоръчваните парньори на cPanel вероятно и при вас го има ама не знаете за него или не знаете че е бъг :lol:
 
От: VPS + Wp + W3 Total Cache - оптимизация

Сега излиза с друга картинка... вече изглежда добре.

Поизчистих някои стари файлове. Сега трябва да зарежда добре и на chrome incognito.
 
Re: От: VPS + Wp + W3 Total Cache - оптимизация

ама не знаете за него или не знаете че е бъг :lol:

Сори на всички, че ще спамна ... ама в духа на "It's not a bug, it's a feature" ....

tumblr_ma07lpuVT91qz503po1_500.jpg

Поизчистих някои стари файлове. Сега трябва да зарежда добре и на chrome incognito.

Проблема от по-горе вече го няма.

А за инкогнито моуд - популярен е в п0рн0 средите :) Майтапа на страна, ползва се за да не се пазят временни файлове, бисквитки и още каквото се сетиш. Накратко, все едно всеки път ползваш нова инсталация на браузъра, т.е. изключваш вариантите на компютъра ти да има кеширана информация от сайта. Ползвам го често, когато правя редакции по css файловете и заменям изображения, за да видя актуалното състояние на сайта. Има го и във фаерфокс ;)
 
От: VPS + Wp + W3 Total Cache - оптимизация

Значи, ние сме дейта център. Ние предлагаме хардуер и опционално съпорт :) Варниш-а го бяхме настроили оптимално и ако си мислиш, че дори не сме отваряли тикет до тях - лъжеш се, нямаш ти най-големия опит в интернет за да говориш такива неща, че ние сме се издънили. Проблемът е, че имат прекалено много заявки (посещения) и варниша гърми като сървис и трябва рестарт (на варниша). Казах ти - дай боже и ти да имаш толкова посещения. Както и да е.

Колкото до cPanel-а ето това му харесвам на виртуалмин-а , че като правиш дейтабейз има отметка "same as administrator password". И паролата си е същата. Според мен би трябвало да НЕ се сменя паролата при смяна на администраторския панел, а паролата за панела да ти е само за панела. Това лично си е мое мнение, ама понеже cPanel са ориентирани към ... по-ниско ниво на IT специалисти са го направили максимално лесно - сменяш една парола и айдеееее, вичко 6.

Добре де, аз този проблем не съм го виждал, до сега никой не е ревал за това (имаме 300+ лиценза cPanel). Какво по-точно става като смениш паролата ?Можеш ли да влезеш в phpmyadmin със старата парола? Или успяваш да влесеш със новата ? Проблема изпробва ли го с отделен phpmyadmin (такъв, който ти се намира в отделна папка на сайта) или се опитваш през контролния панел да влезеш в него ? Ако на отделния phpmyadmin работи новата парола значи се е синхронизирала и проблема ти е някъде в автентикационния метод на phpmyadmin. Такъв проблем имах и с един pma на един плеск сървър - решението беше в един от файловете да коментирам един ред и да добавя нещо от сорта на "$host = 'localhost';" или нещо подобно, не помня вече.

Не говори добре за един администратор ъпдейтването на даден продукт без да се допита до мнение на други администратори - в случая да провериш от топ10 препоръчани партньори дали няма бъгове преди да ъпдейтваш. :) Не го казвам за да обиждам, просто градивна критика. Преди да ъпдейтваш до последна версия провери дали няма някой голям бъг.

ЕДИТ:

Пак повтарям - ние предоставяме ХАРДУЕР, ние не сме web администратори и не е наша работа да ъпдейтваме каквото и да било. Наша става, като си платиш 180лв за час. Всеки, който си вземе сървър си отговаря за това което слага там, стига да не нарушава правилата. Ако ще и празен да го държи. Имахме един клиент с 10-тина сървъра който един ден просто си спря единия и каза "мигриран е , оставете го изключен до края на договора." И си го плащаше като пич. Ако някой ъпдейтне cPanel при нас и не е доволен нашата работа е до там, че да отворим билет със техния съпорт, разменят се ключове и те го оправят дистанционно. Не знам дали твоя случай попада в тази категория, но при нас помоща при cPanel е лимитирана - 3rd party e. Точка. Ако те го оправят - оправят, ако не - носиш си сам последствията. Ето защо и клиентите рядко се навиват да ъпдейтват винаги до последна версия. Повечето от тях си стоят с 2-3 версии по-стара от най-новата. А, разбира се имаме и такива , които като им го инсталираме и не го пипат - само слагат сайтове...
 
Последно редактирано:
От: VPS + Wp + W3 Total Cache - оптимизация

Поизчистих някои стари файлове. Сега трябва да зарежда добре и на chrome incognito.

Вече сайта ти зарежда за 3,5 сек. Добре е - 30% по-бърз. Ако искаш още да намалиш бързодействитето - виждам, че използваш доста външни библиотеки (js, fonts) от най-различни места. По възможност ги свали и ги тури в папките на сайта и ги инклудвай оттам. Преди поддържах един сайт, който беше с такива библиотека докато не започнаха много да се дънят - я от доставчици на свързаност, я от ъпдейт/ъпгрейд на услугата... ня ъпдейтнали js-a и това, което използвам вече не работи като преди... Затова ги свалих, в папката - редактирах темата, че да ги инклудва от папка и всичко работеше на 6 ( и все още работи ), че и по-бързо.

Пак подчертавам - ПРИ ВЪЗМОЖНОСТ. Защото ти ако използваш плъгини за тези работи може те самита да си инклудват тези неща и да нямаш власт над тях :)
 
От: VPS + Wp + W3 Total Cache - оптимизация

deanski нещо супер, мега, бруталното самочуствие вади :D

Ти какво искаш сега? Казах му, че Варниш беше настроен оптимално, дори пускахме тикет към тях, самите разработчици казаха, че няма какво да се направи повече, а той ми вика знам къде сте се издънили. Хаха, смях. Самият Варниш е лимитиран по ресурси - при по-ниска стойност има опасност на приложението да не работи, при по-висока има опасност да ти изяжда рам-а, независимо колко имаш. Просто този сайт беше време да се скалира на няколко app сървъра с лоуд балансър, ама какво да ги правиш - скръндзи.

Едит: аз за този случай говоря обективно, възможно е да не изкарват чак толкова пари за този сайт за да си позвоят 3-4 сървъра + лоуд балансър, но като си се надупил нали знаеш - по-добре се отпусни :)

Едит2: Искам да подчертая също, че на този сървър му крашваше САМО варниш-а, апачи продължаваше да си работи.
 
Последно редактирано:
Re: От: VPS + Wp + W3 Total Cache - оптимизация

Значи, ние сме дейта център. Ние предлагаме хардуер и опционално съпорт :) Варниш-а го бяхме настроили оптимално и ако си мислиш, че дори не сме отваряли тикет до тях - лъжеш се, нямаш ти най-големия опит в интернет за да говориш такива неща, че ние сме се издънили. Проблемът е, че имат прекалено много заявки (посещения) и варниша гърми като сървис и трябва рестарт (на варниша). Казах ти - дай боже и ти да имаш толкова посещения. Както и да е.

Колкото до cPanel-а ето това му харесвам на виртуалмин-а , че като правиш дейтабейз има отметка "same as administrator password". И паролата си е същата. Според мен би трябвало да НЕ се сменя паролата при смяна на администраторския панел, а паролата за панела да ти е само за панела. Това лично си е мое мнение, ама понеже cPanel са ориентирани към ... по-ниско ниво на IT специалисти са го направили максимално лесно - сменяш една парола и айдеееее, вичко 6.

Добре де, аз този проблем не съм го виждал, до сега никой не е ревал за това (имаме 300+ лиценза cPanel). Какво по-точно става като смениш паролата ?Можеш ли да влезеш в phpmyadmin със старата парола? Или успяваш да влесеш със новата ? Проблема изпробва ли го с отделен phpmyadmin (такъв, който ти се намира в отделна папка на сайта) или се опитваш през контролния панел да влезеш в него ? Ако на отделния phpmyadmin работи новата парола значи се е синхронизирала и проблема ти е някъде в автентикационния метод на phpmyadmin. Такъв проблем имах и с един pma на един плеск сървър - решението беше в един от файловете да коментирам един ред и да добавя нещо от сорта на "$host = 'localhost';" или нещо подобно, не помня вече.

Не говори добре за един администратор ъпдейтването на даден продукт без да се допита до мнение на други администратори - в случая да провериш от топ10 препоръчани партньори дали няма бъгове преди да ъпдейтваш. :) Не го казвам за да обиждам, просто градивна критика. Преди да ъпдейтваш до последна версия провери дали няма някой голям бъг.

ЕДИТ:

Пак повтарям - ние предоставяме ХАРДУЕР, ние не сме web администратори и не е наша работа да ъпдейтваме каквото и да било. Наша става, като си платиш 180лв за час. Всеки, който си вземе сървър си отговаря за това което слага там, стига да не нарушава правилата. Ако ще и празен да го държи. Имахме един клиент с 10-тина сървъра който един ден просто си спря единия и каза "мигриран е , оставете го изключен до края на договора." И си го плащаше като пич. Ако някой ъпдейтне cPanel при нас и не е доволен нашата работа е до там, че да отворим билет със техния съпорт, разменят се ключове и те го оправят дистанционно. Не знам дали твоя случай попада в тази категория, но при нас помоща при cPanel е лимитирана - 3rd party e. Точка. Ако те го оправят - оправят, ако не - носиш си сам последствията. Ето защо и клиентите рядко се навиват да ъпдейтват винаги до последна версия. Повечето от тях си стоят с 2-3 версии по-стара от най-новата. А, разбира се имаме и такива , които като им го инсталираме и не го пипат - само слагат сайтове...

Продукта има няколко бранша и уж е тестван (което не пречи да са си оставили ръцете) чак до стейбъл версията

attachment.php


cPanel препоръчват да си на Release...

Stable - старта версия

Преди Release има Edge и Current


Ако ще се дъвкаме :).... клиентите който не са ъпдейтвани в последните 20 дни до последния релииз си ходят с тези бъгове (някой са секюрити)

НЕ говори добре за Админ който не спазва препоръчаното от вендора, особено за ъпдейти който оправя проблеми със секюрити...

Оделно случая е много по тежък и имаш мулти потребителска среда, до която всеки има достъп автоматичен достъп след като плати малка такса

Като е еденичен клиент вингаи може (да му кажеш да не ъпдейтва и че риска си е за него, и като само той си има достъп до машината и ползва cPanel за улеснение е е малко по защитен и със старата (понецже някой са локални експлоити), ако е с публичен достъп може и да изреве)

А последната Release версия оправя една камара други неща...
https://documentation.cpanel.net/display/ALD/11.44+Change+Log

Ако не си ъпдейтнал от 11.44.0 на 11.44.1 в края на миналия месец
11.44.1.15


2014-08-13
  • Fixed case 39210: Transferring reseller-owned account doesn't give dedicated IP.
  • Fixed case 103453: Fixed issue with file editor appending/prepending white spaces.
  • Fixed case 104025: Install /etc/init.d/httpd for Apache 2.4.
  • Fixed case 104725: Update MySQL50 to 5.0.96-3.cp1136.
  • Fixed case 104729: Update MySQL51 to 5.1.73-2.cp1136.
  • Fixed case 105285: Account for cloudlinux within the parent_check() call.
  • Fixed case 105585: Prefer remote shells over ssh in order of /bin/bash, /usr/local/bin/bash, /bin/sh.
  • Fixed case 106401: Auto-adjust innodb_buffer_pool_size.
  • Fixed case 106409: Check to see if MySQL is running after an upgrade.
  • Fixed case 106561: TailWatch::Chkservd::_increment_restart_count does not report errors.
  • Fixed case 106689: Update MySQL51 to 5.1.73-3.cp1136.
  • Fixed case 106689: Update compat-MySQL51-shared to 5.1.73-3.cp1136.
  • Fixed case 106829: Fixed issue with uploading a certificate in Paper Lantern.
  • Fixed case 107113: Restore the documentroot from the source userdata on transfer.
  • Fixed case 107201: Modify Account validation is too strict for underscores.
  • Fixed case 107713: Deal with log and log-slow-queries not having values.
  • Fixed case 107725: Properly chown DKIM private key files on transfer.
  • Fixed case 107725: Provide a function to look up DKIM key paths.
  • Fixed case 107873: Character encoding of Mailman configuration data corrupted during xfer.
  • Fixed case 107885: Fix locale typo in Cpanel::Mysql::privs.
  • Fixed case 108161: Ensure MySQL and Postgres are online before changing usernames.
  • Fixed case 108193: Transferring an account as a user can never timeout.
  • Fixed case 108261: Create script to repair innodb tables after upgrade.
  • Fixed case 108381: Backup Restore Archive copy timeout is too low.
  • Fixed case 108393: Packages with the same case insensitive name cannot be transfered.
  • Fixed case 108493: Improve the error if TempFile creation fails during transfer setup.
  • Fixed case 108793: Remove authinfo requirement from AccountBase.pm.
  • Fixed case 108861: Check to ensure Postgres is online before starting transfer.
  • Fixed case 108897: All MySQL RPMs fail, with a "cannot connect" error.
  • Fixed case 108909: Update MySQL50 to 5.0.96-4.cp1136.
  • Fixed case 108909: Update compat-MySQL50-shared to 5.0.96-4.cp1136.
  • Fixed case 108913: Update MySQL55 to 5.5.37-2.cp1136.
  • Fixed case 108997: Fix data buffering in account transfers with user pass.
  • Fixed case 109061: MySQL upgrade can fail with an error indicating cannot connect.
  • Fixed case 109093: Fix failure of checkdbs with moderated list users.
  • Fixed case 109525: Improve the error message on remote shell timeout.
  • Fixed case 109529: Warnings for older MySQL version.
  • Fixed case 109557: MySQL upgrades fail due to missing use.
  • Fixed case 109605: Ensure build_mysql_conf does not error when libmariadb.so.1 is missing.
  • Fixed case 109713: Clarify MySQL upgrade UI.
  • Fixed case 109749: Simplify compat-MySQL changes when upgrading to 5.5 or later.
  • Fixed case 109913: MySQL Upgrade fixes and localization tweaks.
  • Fixed case 110033: utf8mb4 database dumps fail to restore on MySQL 5.0.
  • Fixed case 110053: Cannot upgrade to MySQL 5.5 if /v/c/rpm.version.d says it's uninstalled.
  • Fixed case 110065: Re-enabled EVENT and TRIGGER in MySQL >= 5.1.
  • Fixed case 110221: Fix incorrect name for MySQL 5.0 RPM target.
  • Fixed case 110281: Improved error when user conflicts with db/dbuser.
  • Fixed case 110433: Forbid suspending reserved users.
  • Fixed case 111037: Ensure MySQL version is correctly detected after upgrade.
  • Fixed case 111045: WHM was not rewriting /etc/my.cnf on upgrades as it should.
  • Fixed case 111197: Update MySQL51 to 5.1.73-4.cp1136.
  • Implemented case 94037: Restore MySQL 3.x passwords with a random new password under MySQL 5.6+.
  • Implemented case 104745: Install the compat-MySQL50, compat-MySQL51 when updating to 5.5 or later.
  • Implemented case 105181: Safely shutdown MySQL by every means possible.
  • Implemented case 105185: Simplify MySQL root password resets.
  • Implemented case 107665: Prevent the root MySQL user from being connection limited.
  • Implemented case 107697: Simplify the transfer session object init process to avoid sql selects.
  • Implemented case 107701: Remove Net::MySQL workarounds from the transfer system.
  • Implemented case 108941: MySQL 5.0/5.1 compatibility fixes for 11.44.
11.44.1.11


2014-08-04
  • [security] Fixed case 108965: Bypass of account suspension via mod_userdir.
11.44.1.7


2014-07-23
  • Fixed case 72765: Don't warn about timeout if legacy backups are disabled.
  • Fixed case 103829: Deal with /tmp/mysql.sock error for mysql upgrade.
  • Fixed case 103897: Have mailing list page deal with unreasonably long list names.
  • Fixed case 106345: Transfers abort with SIGPIPE if the mysql timeouts are too low.
  • Fixed case 106361: Find the correct mysql socket file on startup.
  • Fixed case 106537: Safekill can block until timeout when trying to kill a child process.
  • Fixed case 106569: Add the my.cnf sanity check to RestoreQueue path.
  • Fixed case 106633: Add support for .pck files with utf-8 and unicode data.
  • Fixed case 106653: Increase the restore system extraction timeout to 12 hours from 30 minutes.
  • Fixed case 106693: Update cpanel-mariadb-native-client to 1.0.1-3.cp1136.
  • Fixed case 106693: Use an 11.42 RPM for cpanel-mariadb-native-client.
  • Fixed case 106717: Fix random failure in homedir streaming.
  • Fixed case 106781: Only check the first eight characters for uniqueness.
  • Fixed case 106985: Fix restore of mysql grants for users with a "." or "_".
  • Fixed case 106993: Fix DBI connection error when running cpanellogd for a single user.
  • Fixed case 107001: Allow user to upgrade from MySQL 4.1 all the way to 5.6.
  • Fixed case 107105: Initial install of cPanel w/ Apache MPM ITK properly sets up suEXEC.
  • Fixed case 107349: Properly re-encode mailman users' names.
  • Fixed case 107489: Explicitly specify the pickle protocol version.
  • Fixed case 107621: Temporary fix for VPS image issues.
  • Fixed case 107801: Downgrade unicode in converted pickle files where possible.
  • Implemented case 105201: Auto migrate my.cnf to support mySQL 5.5/5.6 if the restart fails.
  • Implemented case 107005: Updated cpanel-mariadb-native-client to 1.0.1-4.cp1136.
11.44.1.6


2014-07-22
  • [security] Fixed case 105465: Update Exim to 4.82-4.cp1136 for CVE-2014-2972.
11.44.0.30


2014-07-22
  • [security] Fixed case 105465: Update Exim to 4.82-4.cp1136 for CVE-2014-2972.
11.44.1.5


2014-07-21
  • [security] Fixed case 93321: Limited arbitrary file modification via LeechProtect subsystem.
  • [security] Fixed case 98125: Process locking based on 'ps' vulnerable to attack by local users.
  • [security] Fixed case 98253: Insecure permissions on eximstats SQL password file.
  • [security] Fixed case 99353: Self-stored XSS vulnerability in WHM SSH key management interface.
  • [security] Fixed case 99637: Stored XSS vulnerability in WHM listaccts interface.
  • [security] Fixed case 99749: Bypass of account ownership restrictions during account creation.
  • [security] Fixed case 99861: Update analysis logs sent without proper SSL certificate validation.
  • [security] Fixed case 100669: Self-Stored XSS Vulnerability in WHM Manage Custom RBLs.
  • [security] Fixed case 100677: Arbitrary file unlink via fixwebalizer script.
  • [security] Fixed case 100685: Stored XSS Vulnerability in WHM Email All Users.
  • [security] Fixed case 100957: Arbitrary YAML file read via import_old_support_cfg script.
  • [security] Fixed case 101013: Self-stored XSS Vulnerability in WHM Disk Usage.
  • [security] Fixed case 102105: Bypass of account suspension via mail filters.
  • [security] Fixed case 102401: Limited SQL injection vulnerability in LeechProtect.
  • [security] Fixed case 102853: Self XSS Vulnerability in WHM EasyApache Launcher.
  • [security] Fixed case 102877: Self XSS Vulnerability in WHM Legacy Language File Upload.
  • [security] Fixed case 103341: Arbitrary code execution via Mailman pickle files.
  • [security] Fixed case 104101: Self-stored XSS vulnerability in view_cert.tt.
  • [security] Fixed case 104105: Self-stored XSS vulnerability in view_key.tt.
  • [security] Fixed case 105273: Self-stored XSS vulnerability in view_csr.tt.
  • [security] Fixed case 105345: Arbitrary file read via Exim virtual aliases.
  • [security] Fixed case 105469: Bypass of commondomains and hostname restrictions in WHM Add DNS interface.


Спора тръгна за бързия съпорт на cPanel - мен точно за такива неща ми трябва съпорт и като ги бавят по цял месец понякога е тежко за тези който продаваме услуги на крайни клиенти... съпорта не е бърз просто се води най добрия панел на пазара а и клиентите толкова са свикнали с него че с го искат... Аз казвам че съпортна на цпанел грам не е бърз...


Сега ще напиша какво е станало с варниша

Клиента е имал проблем с бавенето и някой от вашите или администратор на клиента е инсталирал варниш със 7 простички команди (да така се инсталира дефултен) сайта е поолекнал но се появила висока дискова активност... Някой без много да погледне понеже в големите фирми клиентети са просто номер на фактура (отделяш малко време на някой номер на бързо и минаваш към следващия номер ) е казал базите и се появила машината за mysql със SSD (да сигурно в 9 от 10 случая щеше да е напълно прав) но при варниш от файл на диска (дефултна инстлация) и много трафик се случва варниша да използва диска по агресивно от нея.... и да става приятно бозещо и нестабилно :) Обичаен симптом на бозещ сайт със варниш при много връзки (точно както го описа)

Ако не е това е дефултния vcl (но за там вече да взема и аз да обявя тарифа на час щом взиамта по 180)

Хубаво взимате няколко пъти повече отколкото взимам аз но като сте по хардуера и само са ви взели сертификация но това не ви прави най добрите (най малкото за Варниш няма сертификация трябва практика... дори да имате някой който много го разбира варниша не можете да отделите цяло време на едно номерче на фактура освен ако не си плати дебело... а дори и да си плати и като свърши смяната човека който го разбира си тръгва поема другия като има само бегла представа какво е се случва с горния кейс...
 

Прикачени файлове

  • tiers.png
    tiers.png
    63.6 KB · Преглеждания: 29

Горе