Joomla 4. Компонент K2 и форк K2ForJ4 (18 янв 2024)

Если вас, как и меня, достало выслушивать (вычитывать) бесконечные обещания разработчика K2 опубликовать версию компонента K2 под Joomla 4 (без чего невозможно реализовать апгрейд from Joomla 3 to Joomla 4) - воспользуйтесь форком K2ForJ4. Который в данный момент установлен и без каких-либо проблем работает на этом веб-сайте.

SpaceWeb: VDS на базе KVM - 1 месяц бесплатно

Больше
7 года 10 мес. назад - 7 года 10 мес. назад #1 от Aleksej
Вот такое вот письмо получил.... уже воспользовался приглашением и тестирую. Как раз нужна в хозяйстве виртуалка для тестов. Кто заинтересовался, присоединяйтесь - думаю, SpaceWeb не обидится, если я его немного попиарю? .


Вы являетесь зарегистрированным пользователем хостинга SpaceWeb.
Ваш логин: ****************
Номер Вашего договора: *****************
Рады Вам сообщить, что в скором времени SpaceWeb запустит новую услугу – VDS на базе технологии KVM с SSD!
У Вас как у нашего клиента есть шанс попробовать эту услугу еще до ее открытия, и притом совершенно бесплатно! Торопитесь – количество бесплатных VDS на KVM ограничено.

Для того чтобы получить целый месяц бесплатного пользования VDS на KVM, просто зарегистрируйтесь на тарифе KVM-1 (Beta) по адресу sweb.ru/vds-kvm/ .

После коммерческого запуска услуги при желании Вы сможете продолжить пользоваться услугой на платной основе. О ценах и тарифах сообщим дополнительно.
Ждем Ваших отзывов, замечаний и пожеланий о работе сервиса.
Если у Вас возникнут какие-либо вопросы, Вы можете обратиться в службу технической поддержки нашей компании. Наши специалисты всегда рады Вам помочь!

--
С уважением,
отдел технической поддержки
хостинг-провайдер SpaceWeb
в С.-Петербурге +7 (812) 334-1222
в Москве +7 (495) 663-1612
8 (800) 100-16-15 (бесплатная горячая линия по России)

Последнее редактирование: 7 года 10 мес. назад пользователем Aleksej.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Dev banner 3
Больше
7 года 10 мес. назад - 7 года 10 мес. назад #2 от serge
Spaceweb - это вам не Амазон , здесь придется хотя б немножко покопаться в firewalld. Открыть тестовую страничку apache после всех конфигов сходу не получается, логично предположить что блокирует firewalld, коли уж мы установили CentOS 7. Посмотрим, что же вообще разрешено на нашей новой виртуальной машине?

Code:
# firewall-cmd --permanent --list-all public (default) interfaces: sources: services: ssh dhcpv6-client masquerade: no forward-ports: icmp-blocks: rich rules:

Удаляем ipv6 (или он вам нужен?):

Code:
# firewall-cmd --permanent --zone=public --remove-service=dhcpv6-client

Откроем 80 порт (у вас ведь веб-сервер, правильно?):

Code:
# firewall-cmd --permanent --zone=public --add-port=80/tcp

Перезагрузим наши правила:

Code:
# firewall-cmd --reload

Проверим:

Code:
# firewall-cmd --zone=public --list-ports 80/tcp


А кстати, какие зоны у нас присутствуют по-дефолту ("зоны" в firewalld используются довольно широко)? -

Code:
# firewall-cmd --get-zones block dmz drop external home internal public trusted work

А какие зоны активны? -

Code:
# firewall-cmd --get-active-zones public interfaces: eth0


и так далее. Все, можно открывать тестовую страничку апача или свой любимый phpmyadmin.

А я смогу! - А поглядим! - А я упрямый!
Последнее редактирование: 7 года 10 мес. назад пользователем serge.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
7 года 10 мес. назад - 7 года 10 мес. назад #3 от Aleksej
Backtrace... дебаг говорит, что, похоже, пых валится на коннекте к Mariadb.... использовался php 5.6.20 из Webtatic. Шут его знает, на другом моем сервере этот самый пых работает без каких-либо ощутимых проблем, а здесь, на Спейсвебе... странно. Отослал сообщение обоим, фиг его знает. Хотя сомнения у меня немалые, что и тот и другой будут с этим разбираться.. короче вот, если кто заинтересуется:


Code:
Program received signal SIGPIPE, Broken pipe. [Switching to Thread 0x7ffff7feb840 (LWP 30343)] 0x00007ffff6ad06cd in __libc_send (fd=18, buf=0x555555cae500, n=22, flags=64) at ../sysdeps/unix/sysv/linux/x86_64/send.c:27 27 return INLINE_SYSCALL (sendto, 6, fd, buf, n, flags, NULL, (size_t) 0); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-13.el7.x86_64 cyrus-sasl-lib-2.1.26-20.el7_2.x86_64 elfutils-libelf-0.163-3.el7.x86_64 elfutils-libs-0.163-3.el7.x86_64 freetype-2.4.11-11.el7.x86_64 gmp-6.0.0-12.el7_1 .x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.13.2-12.el7_2.x86_64 libX11-1.6.3-2.el7.x86_64 libXau-1.0.8-2.1.el7.x86_64 libXpm-3.5.11-3.el7.x86_64 libattr-2.4.46-12.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-7.el7.x86_64 libcurl-7.29.0-25.el7.centos.x86_64 libgcc-4.8.5-4.el7.x86_64 libgcrypt-1.5.3-12.el7_1.1.x86_64 libgpg-error-1.12-3.el7.x86_64 libidn-1.28-4.el7.x86_64 libjpeg-turbo-1.2.90-5.el7.x86_64 libpng-1.5.13-7.el7_2.x86_64 libssh2-1.4.3-10.el7_2.1.x86_64 libtidy-0.99.0-31.20091203.el7.x86_64 libuuid-2.23.2-26.el7_2.2.x86_64 libxcb-1.11-4.el7.x86_64 libxml2-2.9.1-6.el7_2.2.x86_64 libxslt-1.1.28-5.el7.x86_64 nspr-4.11.0-1.el7_2.x86_64 nss-3.21.0-9.el7_2.x86_64 nss-softokn-freebl-3.16.2.3-14.2.el7_2.x86_64 nss-util-3.21.0-2.2.el7_2.x86_64 openldap-2.4.40-9.el7_2.x86_64 openssl-libs-1.0.1e-51.el7_2.4.x86_64 php56w-5.6.20-1.w7.x86_64 php56w-bcmath-5.6.20-1.w7.x86_64 php56w-common-5.6.20-1.w7.x86_64 php56w-gd-5.6.20-1.w7.x86_64 php56w-mbstring-5.6.20-1.w7.x86_64 php56w-mysqlnd-5.6.20-1.w7.x86_64 php56w-opcache-5.6.20-1.w7.x86_64 php56w-pdo-5.6.20-1.w7.x86_64 php56w-process-5.6.20-1.w7.x86_64 php56w-tidy-5.6.20-1.w7.x86_64 php56w-xml-5.6.20-1.w7.x86_64 sqlite-3.7.17-8.el7.x86_64 t1lib-5.1.2-14.el7.x86_64 xz-libs-5.1.2-12alpha.el7.x86_64 (gdb) bt #0 0x00007ffff6ad06cd in __libc_send (fd=18, buf=0x555555cae500, n=22, flags=64) at ../sysdeps/unix/sysv/linux/x86_64/send.c:27 #1 0x00007fffea4b6ecf in php_sockop_write () from /etc/httpd/modules/libphp5.so #2 0x00007fffea4a9b7e in _php_stream_write_buffer () from /etc/httpd/modules/libphp5.so #3 0x00007fffdc3943de in php_mysqlnd_net_send_ex_pub () from /usr/lib64/php/modules/mysqlnd.so #4 0x00007fffdc38d130 in php_mysqlnd_cmd_write () from /usr/lib64/php/modules/mysqlnd.so #5 0x00007fffdc3844e0 in php_mysqlnd_conn_data_simple_command_send_request_pub () from /usr/lib64/php/modules/mysqlnd.so #6 0x00007fffdc3823ce in php_mysqlnd_conn_data_simple_command_pub () from /usr/lib64/php/modules/mysqlnd.so #7 0x00007fffdc38711b in php_mysqlnd_conn_data_send_query_pub () from /usr/lib64/php/modules/mysqlnd.so #8 0x00007fffdc386f73 in php_mysqlnd_conn_data_query_pub () from /usr/lib64/php/modules/mysqlnd.so #9 0x00007fffdc383fb8 in php_mysqlnd_conn_data_set_charset_pub () from /usr/lib64/php/modules/mysqlnd.so #10 0x00007fffdbf5b5e5 in zif_mysqli_set_charset () from /usr/lib64/php/modules/mysqlnd_mysqli.so #11 0x00007fffea4e5c6b in dtrace_execute_internal () from /etc/httpd/modules/libphp5.so #12 0x00007fffea59f154 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #13 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #14 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #15 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #16 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #17 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #18 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #19 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #20 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #21 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #22 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #23 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #24 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #25 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #26 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #27 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #28 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #29 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #30 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #31 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #32 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #33 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #34 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #35 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #36 0x00007fffea59f609 in zend_do_fcall_common_helper_SPEC () from /etc/httpd/modules/libphp5.so #37 0x00007fffea533a48 in execute_ex () from /etc/httpd/modules/libphp5.so #38 0x00007fffea4e5b49 in dtrace_execute_ex () from /etc/httpd/modules/libphp5.so #39 0x00007fffea4f886b in zend_execute_scripts () from /etc/httpd/modules/libphp5.so #40 0x00007fffea493d62 in php_execute_script () from /etc/httpd/modules/libphp5.so #41 0x00007fffea5a0d7d in php_handler () from /etc/httpd/modules/libphp5.so #42 0x0000555555593270 in ap_run_handler (r=r@entry=0x555555b9e690) at config.c:169 #43 0x00005555555937b9 in ap_invoke_handler (r=r@entry=0x555555b9e690) at config.c:439 #44 0x00005555555a7b3a in ap_process_async_request (r=r@entry=0x555555b9e690) at http_request.c:317 #45 0x00005555555a7e14 in ap_process_request (r=r@entry=0x555555b9e690) at http_request.c:363 #46 0x00005555555a47a2 in ap_process_http_sync_connection (c=0x555555b952e0) at http_core.c:190 #47 ap_process_http_connection (c=0x555555b952e0) at http_core.c:231 #48 0x000055555559c840 in ap_run_process_connection (c=c@entry=0x555555b952e0) at connection.c:41 #49 0x000055555559cc28 in ap_process_connection (c=c@entry=0x555555b952e0, csd=<optimized out>) at connection.c:202 #50 0x00007fffeda1980f in child_main (child_num_arg=child_num_arg@entry=0) at prefork.c:707 #51 0x00007fffeda19a55 in make_child (s=0x555555800320, slot=slot@entry=0) at prefork.c:810 #52 0x00007fffeda19ab6 in startup_children (number_to_start=5) at prefork.c:828 #53 0x00007fffeda1a7c0 in prefork_run (_pconf=<optimized out>, plog=0x555555804358, s=0x555555800320) at prefork.c:986 #54 0x00005555555795ae in ap_run_mpm (pconf=pconf@entry=0x5555557d7138, plog=0x555555804358, s=0x555555800320) at mpm_common.c:96 #55 0x0000555555572b36 in main (argc=2, argv=0x7fffffffe0d8) at main.c:777 (gdb) q A debugging session is active.

P.S. Родной php -

Code:
# php -v PHP 5.4.16 (cli) (built: Jun 23 2015 21:17:27) Copyright (c) 1997-2013 The PHP Group

работает на спейсвебовском центосе без проблем, ошибка исчезает. Но это ведь не выход, прецеденты уже имели место . А адекватного пыха в репах RedHat/Centos по сию пору нет. Можно из Remi's RPM repository установить php, вместо Webtatic. Но тоже ведь неофициальный реп.
Последнее редактирование: 7 года 10 мес. назад пользователем Aleksej.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Больше
7 года 10 мес. назад #4 от Aleksej
Последовательность шагов, step-by-step; так, как описывал их в кратком отчете для SpaseWeb и на Unixforum-e:

И Вы уверены, что дело в сборке php, а не в том, например, что файрвол режектит пакеты?


да, я уверен в том, что firewalld здесь ни при чем. Что касается неофициального php - не знаю, в этом и заключается вопрос.

Постараюсь описать последовательность шагов... ок, я по-быстрому опишу процесс установки репозиториев и пакетов, это будет вполне точный репродьюс, т.к. делал подобное не единожды в контексте RHEL 7.1 и 7.2. Последовательность шагов и синтаксис, возможно, незначительно менялись, сессию не логгировал, пишу по памяти. Но суть неизменна. Версии пакетов - соответственно, те, которые находятся на данный момент в указанных репах; VDS же я получил с уже предустановленным Centos 7.1.

1. разумеется, обновление:

Code:
sudo yum update

далее апач:

Code:
sudo yum install httpd sudo systemctl enable httpd.service sudo systemctl start httpd.service

и mariadb:

Code:
sudo yum install mariadb-server sudo systemctl enable mariadb

рестарт mariadb, запускаем постинсталляционный скрипт и удаляем демки, ставим пароль:

Code:
sudo /usr/bin/mysql_secure_installation

в /etc/my.cnf по привычке прописал utf-8 по-дефолту:

Code:
[mysqld] init_connect=‘SET collation_connection = utf8_unicode_ci’ character-set-server = utf8 collation-server = utf8_unicode_ci [client] default-character-set = utf8

подключаем epel и webtatic:

Code:
rpm -Uvh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm rpm -Uvh https://mirror.webtatic.com/yum/el7/webtatic-release.rpm

после чего уже можно ставить новый php 5.6.20 из webtatic и phpmyadmin из епеля. К слову, последний установился и создал необходимые таблицы в своих базах без малейших проблем. Сервер предназначался для сугубо тестов, это не продакшн, поэтому конфига php практически не касался, разве что включил short_open_tag и сделал минимально необходимые настройки в phpmyadmin:

Code:
$cfg['Servers'][$i]['auth_type'] = ‘http‘;

и прописал свой ip для phpmyadmin.


Далее, распаковал файлы cms в по-умолчанию каталог html (виртуалхосты не делал), подарил (chown) каталог рекурсивно апачу (контекст в данном случае не нужен, т.к. selinux был по-умолчанию отключен), зашел через web (разумеется, предварительно сделав # firewall-cmd --permanent --zone=public --add-port=80/tcp ) и на этапе привязки базы данных к cms наткнулся на странную проблему, дебаг которой уже приводил. Вроде бы все.... буду благодарен за замечания и дельную критику в контексте описанного step-by-step; сертифицированным специалистом по RedHat я не являюсь, но проделывал подобное не единожды... впрочем, варианты всегда возможны и только приветствуются.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Работает на Kunena форум