{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Skurudo Blog(post): заметки с тегом CentOS", "_rss_description": "CentOS (англ. Community ENTerprise Operating System) — дистрибутив Linux, основанный на коммерческом Red Hat Enterprise Linux компании Red Hat и совместимый с ним", "_rss_language": "ru", "_itunes_email": "", "_itunes_categories_xml": "", "_itunes_image": "", "_itunes_explicit": "", "home_page_url": "https:\/\/www.skurudo.ru\/tags\/centos\/", "feed_url": "https:\/\/www.skurudo.ru\/tags\/centos\/json\/", "icon": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083", "authors": [ { "name": "Pavel Galkin", "url": "https:\/\/www.skurudo.ru\/", "avatar": "https:\/\/www.skurudo.ru\/pictures\/userpic\/userpic@2x.jpg?1691593083" } ], "items": [ { "id": "144", "url": "https:\/\/www.skurudo.ru\/all\/ovh-you-failed-your-etc-issue\/", "title": "OVH, you failed your \/etc\/issue!", "content_html": "

После заметки о проблемах установки<\/a> VestaCP на серверах OVH, обнаружилось, что версия дистрибутива указывается не только в Debian, но в на других операционных системах: Ubuntu \/ CentOS. Почему оно так случилось в последних релизах ISOшников сказать сложно, но случилось и на эту тему придется что-то думать. Самый простой способ, скорее всего, административный — помимо универсального инсталлятора давать ссылки на инсталляторы для каждой операционной системы. Ничего позорного здесь в общем-то нет.<\/p>\n

Второй вариант чуть более экзотический и попахивает чисто инженерным подходом. Есть мысль, что нужно при определении операционной системы использовать два источника: т. е. не только \/etc\/issue, но и скажем \/etc\/os-release. Сравнивая данные выбирать, в среде какой операционной системы мы находимся. Причем основным источником видимо придется считать именно os-release.<\/p>\n

PS: Благодаря автоматическому выбору операционной системы сложности могут быть только у владельцев Debain\/Ubuntu. Как видно из элегантного кода пользователи CentOS всегда в выигрыше:<\/p>\n

# Detect OS\r\ncase $(head -n1 \/etc\/issue | cut -f 1 -d ' ') in\r\n    Debian)     type="debian" ;;\r\n    Ubuntu)     type="ubuntu" ;;\r\n    *)          type="rhel" ;;\r\nesac<\/code><\/pre>",
            "date_published": "2016-02-08T00:35:21+03:00",
            "date_modified": "2016-02-08T00:32:47+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "Kimsufi",
                "OVH",
                "Ubuntu",
                "VestaCP"
            ],
            "_date_published_rfc2822": "Mon, 08 Feb 2016 00:35:21 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "144",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "142",
            "url": "https:\/\/www.skurudo.ru\/all\/fix-for-phpmyadmin\/",
            "title": "Патч для phpmyadmin",
            "content_html": "
В рамках поддержки проекта VestaCP<\/a> занялся патчем для phpmyadmin. Основная проблема в том, что дополнительные функции из коробки не работают, также как и contoluser.  Многим пользователям функционал по сути не нужен, он избыточен. Правда, не очень приятно видеть при входе сообщение о том, что у тебя часть функций отключено и не работает — «The phpMyAdmin configuration storage is not completely configured, some extended features have been deactivated».<\/p>\n
За вечер пятницы удалось изобразить скрипт, который правит конфигурационный файл и добавляет недостающие таблицы. Чтобы не возиться с определением версии операционной системы, сделал 3 разных скрипта для centos\/debian\/ubuntu. И еще слегка упростил себе жизнь — не стал изобретать генератор паролей, использовал дополнительный пакет.<\/p>\n
Интереснее было в процессе отладки. Выянил, что пихать много запросов в mysql из баша — это не очень хорошо, далеко не все отрабатывает. Гораздо правильнее разбить на несколько. Как оказалось, 3 и 4 ветка phpmyadmin имеют некоторые отличия. В четвертой ветке некоторые значения задаются явно и в дампе несколько больше таблиц, нежели в 3 версии. Довольно странное отличии в количестве нижних подчеркиваний в названии таблиц: в третьей — одно, в четвертой — два. Думаю, в следующих версиях увеличат :)<\/p>\n
По моим прикидкам скрипт успели протестировать более чем на полусотне серверов, не считая мои и тестовые — все вроде ровненько прошло. На неделе, наверное, закинем на гитхаб<\/s> прогоним тесты повторно.. возможно мой вроде-код даже появится в релизе VestaCP. Код добавил на Github, никакого терпения не хватило :)<\/p>\n
PS: Слегка удивило, что фикс никто не сделал раньше и не сэкономил мне время (специально поискал в интернетах), вроде ничего сложного не было. Подозреваю, что все-таки пользователи тратят на это 5-10 минут и забывают или забивают вовсе :-)<\/p>\n
VestaCP Forum<\/b> — phpmyadmin fixer<\/a>
\nGithub<\/b> — Fixes for phpmyadmin (configuration storage and some extended features) <\/a><\/p>\n
Ubuntu<\/b><\/p>\n
sudo wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-ubuntu.sh \r\n&& chmod +x pma-ubuntu.sh && .\/pma-ubuntu.sh<\/code><\/pre>
Debian<\/b><\/p>\n
wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-debian.sh \r\n&& chmod +x pma-debian.sh && .\/pma-debian.sh<\/code><\/pre>
CentOS<\/b><\/p>\n
wget --no-check-certificate \r\nhttps:\/\/raw.githubusercontent.com\/skurudo\/phpmyadmin-fixer\/master\/pma-centos.sh \r\n&& chmod +x pma-centos.sh && .\/pma-centos.sh<\/code><\/pre>",
            "date_published": "2016-01-17T22:33:54+03:00",
            "date_modified": "2016-06-09T12:35:09+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "MySQL",
                "php",
                "phpmyadmin",
                "Ubuntu",
                "VestaCP",
                "код"
            ],
            "_date_published_rfc2822": "Sun, 17 Jan 2016 22:33:54 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "142",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "98",
            "url": "https:\/\/www.skurudo.ru\/all\/nginx-too-many-open-files\/",
            "title": "Nginx — too many open files",
            "content_html": "
Самое распространенное решение с ошибкой «too many open files», когда увеличение лимитов ulimit (\/etc\/sysctl.conf и \/etc\/security\/limits.conf) не помогает:<\/p>\n
worker_rlimit_nofile 16384;<\/code><\/pre>
Общеизвестное и разрекламированное решение, ноги его растут из документации<\/a>. Однако в связи с широким появлением systemd в Debian 8 Jessie \/ CentOS 7, может возникнуть ситуация, когда перечисленные методы могут и не сработать. Идея фикса в принципе та же, но со стороны модной systemd:<\/p>\n
$ mkdir -p \/etc\/systemd\/system\/nginx.service.d\/\r\n$ nano \/etc\/systemd\/system\/nginx.service.d\/limits.conf<\/code><\/pre>
Оглашаем лимиты для сервиса:<\/p>\n
[Service]\r\nLimitNOFILE=22222<\/code><\/pre>
Перезапускаем сервис и радуемся жизни.
\nРешение применимо и для других сервисов.<\/p>\n",
            "date_published": "2015-11-29T00:20:42+03:00",
            "date_modified": "2015-11-28T22:58:32+03:00",
            "tags": [
                "CentOS",
                "Debian",
                "nginx",
                "systemd",
                "Ubuntu"
            ],
            "_date_published_rfc2822": "Sun, 29 Nov 2015 00:20:42 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "98",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "system\/library\/highlight\/highlight.js",
                    "system\/library\/highlight\/highlight.css"
                ],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4116,
    "_e2_ua_string": "Aegea 11.2 (v4116)"
}